Question

I am about to implement a worker thread with work item queuing, and while I was thinking about the problem, I wanted to know if I’m doing the best thing.

The thread in question will have to have some thread local data (preinitialized at construction) and will loop on work items until some condition will be met.

pseudocode:

volatile bool run = true;

int WorkerThread(param)
{
    localclassinstance c1 = new c1();
    [other initialization]

    while(true) {
        [LOCK]
        [unqueue work item]
        [UNLOCK]
        if([hasWorkItem]) {
            [process data]
            [PostMessage with pointer to data]
        }
        [Sleep]

        if(!run)
            break;
    }

    [uninitialize]
    return 0;
}

I guess I will do the locking via critical section, as the queue will be std::vector or std::queue, but maybe there is a better way.

The part with Sleep doesn’t look too great, as there will be a lot of extra Sleep with big Sleep values, or lot’s of extra locking when Sleep value is small, and that’s definitely unnecessary.

But I can’t think of a WaitForSingleObject friendly primitive I could use instead of critical section, as there might be two threads queuing work items at the same time. So Event, which seems to be the best candidate, can loose the second work item if the Event was set already, and it doesn’t guarantee a mutual exclusion.

Maybe there is even a better approach with InterlockedExchange kind of functions that leads to even less serialization.

P.S.: I might need to preprocess the whole queue and drop the obsolete work items during the unqueuing stage.

Answer 1

There are a multitude of ways to do this.

One option is to use a semaphore for the waiting. The semaphore is signalled every time a value is pushed on the queue, so the worker thread will only block if there are no items in the queue. This will still require separate synchronization on the queue itself.

A second option is to use a manual-reset event which is set when there are items in the queue and cleared when the queue is empty. Again, you will need to do separate synchronization on the queue.

A third option is to have an invisible message-only window created on the thread, and use a special WM_USER or WM_APP message to post items to the queue, attaching the item to the message via a pointer.

Another option is to use condition variables. The native Windows condition variables only work if you’re targetting Windows Vista or Windows 7, but condition variables are also available for Windows XP with Boost or an implementation of the C++0x thread library. An example queue using boost condition variables is available on my blog: http://www.justsoftwaresolutions.co.uk/threading/implementing-a-thread-safe-queue-using-condition-variables.html