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:
Respond to events in as close to real-time as possible
Not lose any events
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 againBut that would be utterly wrong. Suppose that queueControlMessage() is called after unlocking our message queue mutex, but before our thread starts waiting for the main Leap processing thread condition variable signal. The condition variable signals are ephemeral in the extreme. If no thread is waiting at the exact moment the signal is sent, we will...