Re: [Boost-bugs] [Boost C++ Libraries] #5727: race condition between ~basic_condition_variable() and notify_all()

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #5727: race condition between ~basic_condition_variable() and notify_all()
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-12-03 02:16:53

#5727: race condition between ~basic_condition_variable() and notify_all()
  Reporter: sbear.powell@… | Owner: viboes
      Type: Bugs | Status: assigned
 Milestone: To Be Determined | Component: thread
   Version: Boost 1.46.1 | Severity: Problem
Resolution: | Keywords:

Comment (by sbear.powell@…):

 That's mostly correct, but it won't deadlock because notifier.wait(lock)
 will unlock foo's lock while it's waiting.

 So: In 1, foo owns m. In 2, the lamda thread will block until m is
 available. In 3, done is false, so notifier.wait(lock) is called--
 releasing ownership of m. The lambda proceeds, setting done to true,
 unlocking m, and notifying any waiting threads (ie. foo). foo returns from
 its call to notifier.wait(), checks done (which is now true) and can

 (If you want experimental proof that it doesn't deadlock, try running my
 workaround code... the logic is pretty much the same)

 Replying to [comment:1 viboes]:
> I'm surely misunderstanding your code
> {{{
> void foo() {
> condition_variable notifier;
> mutex m, m2;
> mutex::scoped_lock lock(m); //1
> bool done=false;
> thread t([&]{
> mutex::scoped_lock lock(m); //2
> done = true;
> lock.unlock();
> notifier.notify_all();
> });
> while(!done) notifier.wait(lock); //3
> }
> }}}
> Doesn't this code deadlock. In 1 foo owns the lock m. In 2 the lambda
 thread is blocked until the lock variable exits his scope (at the end of
 foo). In 3 As done is false thread foo waits for notifier, which can not
 be notified by the lambda as blocked.
> What am I missing?

Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:07 UTC