On Sep 9, 2013 3:34 AM, "Thomas M" <firespot71@gmail.com> wrote:
>
> Hi,
>
> Consider a boolean variable, a mutex and a condition variable:
>
> // simplified code snippet begin
> bool Continue = false;
> boost::mutex someMutex;
> boost::condition_variable someCondVar;
> // simplified  code snippet end
>
> A number of (boost-)threads check if the boolean variable is set to true in order to continue execution, or otherwise wait for this to happen:
>
> // simplified code snippet begin
> boost::unique_lock<boost::mutex> threadLock(someMutex);
> while (Continue == false)
> {
> someCondVar.wait(threadLock);
> }
> // simplified  code snippet end
>
> and a single controller thread is responsible for setting Continue to true (see snippets below).
> Now the question: Is there a strong point pro or against releasing controllerLock before the notify_all-signal is sent?
> E.g. is there preference for the first or second variant as below (see placement of curly brackets!), or even a need for one to ensure correctness?
>
> // simplified code snippet begin - Variant 1
> // notify_all is issued while controllerLock is still being held
> {
> boost::unique_lock<boost::mutex> controllerLock(someMutex);
> Continue  = true;
> someCondVar.notify_all();
> }
> // simplified  code snippet end
>
> // simplified code snippet begin - Variant 2
> // notify_all is issued when controllerLock has already been released
> {
> boost::unique_lock<boost::mutex> controllerLock(someMutex);
> Continue  = true;
> }
> someCondVar.notify_all();
> // simplified  code snippet end
>

My preference is for variant 2.  It might be an uncommon case, but it is possible for a context switch at any time, and that can lead to a case where the other thread is notified and will yry to acquire the lock,  but the lock is still held by this thread for unknown amount of time.

  Brian