What we have created is a classic producer-consumer pattern, where one thread is producing work and the other is processing the work on the queue. We are trying to make our application take care of the following:
So, we need to be absolutely certain that we handle new items added to the queue as rapidly as possible. A naive implementation might look something like this:
- release message queue lock - (possible race condition here!) - wait for condition variable broadcast - check queue again
But that would be utterly wrong. Suppose that
queueControlMessage() is called after unlocking our message queue mutex, but before our thread starts waiting ...