Re: [Boost-users] [Boost.Thread] Scheduling

From: Ruediger Berlich (ruediger.berlich_at_[hidden])
Date: 2008-08-11 12:27:05

Dear Zeljko,

first of all, thanks for your answer!

Regarding your suggestion that "The condition variable should be signaled
before the lock is unlocked", I have followed the Boost.thread
documentation, as well as the "Thread-Safe Queue using Condition Variables"
tutorial in my implementation. See e.g. here:

http://www.boost.org/doc/libs/1_35_0/doc/html/thread/synchronization.html#thread.synchronization.condvar_ref

and here:

http://www.justsoftwaresolutions.co.uk/threading/implementing-a-thread-safe-queue-using-condition-variables.html

In the second code snipped of the synopsis part of the condition_variable
documentation, the notification is clearly done after the lock has been
destroyed. The lock only exists within the scope.

And Anthony writes "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"

See also the code in the Boost.circular_buffer examples:
<Boost-Root>/libs/circular_buffer/test/bounded_buffer_comparison.cpp :

In the "push_front" function:
[...]
lock.unlock();
m_not_empty.notify_one();
[...]

So all these examples unlock the mutex before doing the notification. 

And I still don't understand why this should not be correct:

In order to reach the part where the notification happens, the function must
have locked the mutex first (and unlocked it right before the
notification). This means that the other threads are either waiting to be
notified through the condition variable, or haven't reached that part yet.
If they are waiting, I can signal them. If they aren't and have been lucky
enough to acquire the lock after my explicit call to unlock(), they need to
check the condition itself ("bool go_" in my case). As it has already been
set to "true" within the protected/synchronized area, everything is fine
and they need no notification. And those threads that have been woken up by
the notification need to acquire the lock first. "bool go_" itself is
protected through the mutex.

Will think about it.

Best, Ruediger