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

attachment set

Mon, 16 Nov 2009 21:43:38 GMT

attachment → TestBoostThread.zip

Mon, 16 Nov 2009 21:47:06 GMT

Just wanted to mention that I am using Visual Studio 2008 on Windows XP.

Replying to 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.

viboes — Fri, 20 Nov 2009 10:26:35 GMT

Replying to 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().

Thu, 26 Nov 2009 14:36:49 GMT

Replying to viboes:

Replying to 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.

viboes — Fri, 27 Nov 2009 01:31:57 GMT

Replying to Shouaib Ahmed <ranashoaib@…>:

Replying to viboes:

Replying to 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.

anonymous — Sun, 06 Jun 2010 12:47:24 GMT

owner, status, milestone changed

viboes — Sat, 07 Jan 2012 23:42:42 GMT

owner changed from Anthony Williams to viboes
status new → assigned
milestone Boost 1.41.0 → To Be Determined

viboes — Wed, 15 Aug 2012 22:09:32 GMT

Why do you need a recursive mutex?

viboes — Wed, 15 Aug 2012 22:21:00 GMT

With

		unsigned int i = 0;
		for (Conditions::iterator it = theConditions.begin();
			it != theConditions.end() && i < 2;
			++it)
		{
			(*it)->notify_one();
			//WORKAROUND_ lockMtx.unlock();
			//WORKAROUND_ Sleep(50);
			cout << "Notified One " << theConditions.size() << endl;
			++i;
			//WORKAROUND_ lockMtx.lock();
		}

only the two first conditions will be notified, so there will be up to 10 threads that will not be notified.

viboes — Fri, 17 Aug 2012 15:39:32 GMT

I think that I understand why it could occur that sometimes some threads are not notified.

Both threads have a lock on theMutex. The underlying OS could choose to schedule the ThreadFuncNotifier thread as many times as it wants. One of the threads ThreadFuncWaiter ends by timeout as the ThreadFuncNotifier is not signaling the specific condition.

Let me know if you don't agree with my analysis. I will close the ticket as there is no evidence there is an issue on the library.

status changed; resolution set

viboes — Sat, 18 Aug 2012 14:52:37 GMT

status assigned → closed
resolution → invalid