[Boost-bugs] [Boost C++ Libraries] #1834: boost::condition drops signals with notify_one()

Subject: [Boost-bugs] [Boost C++ Libraries] #1834: boost::condition drops signals with notify_one()
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2008-04-17 15:21:38


#1834: boost::condition drops signals with notify_one()
---------------------------------------------+------------------------------
 Reporter: Kimon.Hoffmann_at_[hidden] | Owner: anthonyw
     Type: Bugs | Status: new
Milestone: To Be Determined | Component: threads
  Version: Boost 1.35.0 | Severity: Regression
 Keywords: |
---------------------------------------------+------------------------------
 In a rather simple case of multiple threads waiting on a condition
 variable which are resumed by multiple calls to notify_one() we observed
 that since 1.35.0 some of the signals are dropped causing some threads to
 block forever.

 Attached is the (rather minimal) asynchronous queue implementation the we
 have used for quite some time now together with a simple test application
 that reproduces the problem.

 The problem was observed on several machines, both Single- and Multi-Core
 running both Windows XP SP2 and Windows Vista Business SP1. In all cases
 the test application was compiled with the Microsoft Visual Studio.Net
 2005 SP1 compiler.

 We have observed that the issue is more likely to appear when:[[BR]]
 1. There is some load on the system[[BR]]
 2. The program is executed from within the Visual Sutio 2005
 debugger.[[BR]]

 A concrete scenario where we could reproduce the problem quite
 reliably:[[BR]]
 1. Start the task manager[[BR]]
 2. Start the test application within the VS 2005 Debugger[[BR]]
 3. Activate the task manager and monitor the thread count within the
 process list.[[BR]]

 Quite often (~ 2 out of 3 runs) the thread count stops changing a certain
 number, which marks the point at which all notify_one calls have been
 made, but not all threads have been awoken as a result.
 When the debugger is now used to break the application, all the remaining
 threads are waiting with interruptible_wait. Viewing the element count of
 the queue reveals that all elements have been successfully inserted into
 the queue, which is why we assume that some of the associated
 notifications have been dropped.

 While this problem can easily be avoided by replacing the notify_one()
 call with a call to notify_all(), we still believe that this is a bug in
 the new threads implementation as this queue (and it's associated unit-
 tests, which first showed the problem) have worked reliably with previous
 versions of Boost.

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


This archive was generated by hypermail 2.1.7 : 2017-02-16 18:49:57 UTC