Re: [Boost-bugs] [Boost C++ Libraries] #3628: condition.notify_one() does not wake up a thread that is in condition.wait() or condition.timed_wait()

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #3628: condition.notify_one() does not wake up a thread that is in condition.wait() or condition.timed_wait()
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2009-11-27 01:31:58

#3628: condition.notify_one() does not wake up a thread that is in
condition.wait() or condition.timed_wait()
--------------------------------------------------+-------------------------
 Reporter:  Shouaib Ahmed <ranashoaib@…>          |       Owner:  anthonyw
     Type:  Bugs                                  |      Status:  new     
Milestone:  Boost 1.41.0                          |   Component:  thread  
  Version:  Boost 1.40.0                          |    Severity:  Problem 
 Keywords:  condition                             |  
--------------------------------------------------+-------------------------

Comment(by viboes):

 Replying to [comment:3 Shouaib Ahmed <ranashoaib@…>]:
 > Replying to [comment:2 viboes]:
 > > Replying to [ticket:3628 Shouaib Ahmed <ranashoaib@…>]:
 > > > You can see in the attached project's TestBoostThread.cpp file that
 in ThreadFuncWaiter(), the thread is in timed_wait() call before it
 releases the mutex to let the ThreadFuncNotifier() thread notify it. But
 inside notify_one(), most of the time it will choose not to notify any
 "waiter". The total_count class member is 0 when that happens. If I
 uncomment the three lines marked as WORKAROUND_ in TestBoostThread.cpp,
 then the threads will be notified, but this is just a workaround.
 > >
 > > Have you tried to protect with a mutex the theConditions variable?
 This variable is used by ThreadFuncNotifier() and  ThreadFuncWaiter().
 >
 > It is protected by a mutex. May be you overlooked that.


 You are right, I overlooked this mutex.

 To which total_count class member are you referring to?

 The explanation I found is that if you don't add the workaround, the
 thread ThreadFuncNotifier will lock the mutex during the iteration through
 the theConditions container + 500 (miliseconds?). This left enough time to
 make the wait for 50 milliseconds to expire. IMO you should not protect
 the Sleep neither in the thread  ThreadFuncNotifier nor ThreadFuncWaiter.

 The //WORKAROUND_ Sleep(50); seems no necessary to me. Does it works
 without?
 HTH.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/3628#comment:4>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.