How many threads, and how distributed?

Topics: Developer Forum
Feb 23, 2007 at 2:59 PM
The major issue that I keep coming up against is how the work is assigned to a thread. The .NET thread pool doesn't strike me as the right approach because worker threads are intended to get in and get out quickly. So, a different threading model is required. But it also begs the question, what kind of infrastructure would be needed to deal with issues such as thread creation and processor utilization?

For example, it makes no sense to distribute work across 50 threads if you have two cores and each of those threads is going to utilize the core 100%. However, the thread is waiting for completion of other events (perhaps I/O, etc), then it does make sense.

What sort of plans do you have for addressing these issues? Is there (and can there be) a clean separation of concerns between the work list and the assignment of a work item to a thread? If that were possible, then different engines for assigning the work item could be explored without affecting the core concepts of mailboxes/ports and pattern/selectors.

Marc
Coordinator
Mar 16, 2007 at 4:29 PM
"The major issue that I keep coming up against is how the work is assigned to a thread. The .NET thread pool doesn't strike me as the right approach because worker threads are intended to get in and get out quickly. So, a different threading model is required. But it also begs the question, what kind of infrastructure would be needed to deal with issues such as thread creation and processor utilization?"

In the general case, the TP works pretty well. As you point out, most cases, you don't want to start a thread per work item, as if that was desired, you would not need any of this and could just start threads passing ThreadStart delegate and go. On the other hand, there are times when you want more threads and your own thread pool. I may need 1 thread per client connection for example upto some max and what to leave the TP for io tasks. In this case, we could use a custom Dispatcher (i.e. tp) using our own TP logic. The CCR has this option, I have not added that yet.

"For example, it makes no sense to distribute work across 50 threads if you have two cores and each of those threads is going to utilize the core 100%. However, the thread is waiting for completion of other events (perhaps I/O, etc), then it does make sense."

Exactly. Good point. The thread pool is designed for exactly that. If you have say max 4 threads in the thread pool and 2 cores, the thread pool will start 2 threads. If one of those threads blocks on IO (which mostly happens eventually), another thread is released upto max threads. This now means 3 threads will be running when t2 unblocks. It is not ideal as now 2 threads will be competing for cpu time, but it works pretty well in general. There is some studder because of built in lag times so not to start and stop thread in a spastic way which would void most benefit from TP.

"What sort of plans do you have for addressing these issues? Is there (and can there be) a clean separation of concerns between the work list and the assignment of a work item to a thread? If that were possible, then different engines for assigning the work item could be explored without affecting the core concepts of mailboxes/ports and pattern/selectors."

Plan is to at least as a custom Dispatcher that does its own TP. So there is a pretty clean separation of work list and worker today because we can swap Dispatchers with no change to other code and the selectors don't care what dispatcher is used - all they know is they run. If you mean other, please explain. It is an interesting topic.