Notes

Multi Threading Notes:


* condition variables can be subject to spurious wake-ups, so it is important to check the actual condition being waited for when the call to wait returns.
* The call to notify_one comes after the data is pushed on the internal queue. This avoids the waiting thread being notified if the call to the_queue.push throws an exception.



[Potential] Issues with thread-safe queue using mutex and condition_variable

1. Should NOT be used for multi-threading: Using Wrapper Class over STL Queue with mutex and condition variable, """ IS """" thread-safe. However, it cause RACE CONDITION for multi-threading. This design is subject to race conditions between calls to empty, front and pop if there is more than one thread removing items from the queue, but in a single-consumer system (as being discussed here), this is not a problem.

void push(Data const& data)
{
boost::mutex::scoped_lock lock(the_mutex);
bool const was_empty=the_queue.empty();
the_queue.push(data);
if(was_empty)
{
the_condition_variable.notify_one();
}
}
2. As written, the call to notify_one is still within the protected region, which is potentially sub-optimal: the waiting thread might wake up immediately it is notified, and before the mutex is unlocked, in which case it will have to block when the mutex is reacquired on the exit from wait. By rewriting the function so that the notification comes after the mutex is unlocked, the waiting thread will be able to acquire the mutex without blocking: