What multithreading paradigm is described here?

Question

A snippet from Managed Threading Best Practices on MSDN:

Don't control the execution of worker threads from your main program (using events, for example). Instead, design your program so that worker threads are responsible for waiting until work is available, executing it, and notifying other parts of your program when finished. If your worker threads do not block, consider using thread pool threads. Monitor..::.PulseAll is useful in situations where worker threads block.

I want to know what this describes so I can search for basic implementations to start working with.

Answer 1

Sounds like a work pool.

Multiple threads wait on a shared queue of work, taking tasks, executing them, and sending them to other parts of the program via shared synchronization variables.

The basic semantics would be that of an MVar, or other asynchronous channel.

Answer 2

This sounds like a decentralised "Agent" based approach.

The "traditional" way of writing multithreaded code is a bit like a micromanagment at work - the boss hands out all work, and everyone else is expected to wait around expectantly for it to be given to them. Any work that needs to be passed between team members is passed via the boss.

An Agent based approach is like empowering everyone on the team to seek out and get the job done, passing work between the team members as required. The boss knows what's going on, but has a executive monitoring role only.

Answer 3

What the snippet means is that:

Suppose you have a producer-consumer problem for which you have a consumer thread. If you have a dedicated thread(non ThreadPool) then you should use the WaitHandle::WaitOne call to make that thread wait until you have something to process (maybe in a process queue). When the producer is done filling up the queue, it can call WaitHandle::Set() to notify you thread to start processing the queue. WaitOne() is for dedicated threads because it will be expensive to create a new dedicated thread every time you want to process the queue.

DoProcessQueue()
{
    while(RUNTHREAD)
    {
        ... process queue items

        waitHandle.WaitOne(); // will wiat here until producer thread calls Set()
    }
}

ThreadPool threads are recommended for small tasks so if you plan to use WaitOne() then you should not use ThreadPool threads because ThreadPool is a global resource available to every application and blocking the pool threads is not a good option.