|
|
Threads-Devel : |
From: Anthony Williams (anthony_at_[hidden])
Date: 2008-04-08 07:20:05
Quoting Pinho Romulo <romulo.pinho_at_[hidden]>:
> I've been facing deadlock situations using boost 1.33.1 under
> Windows and Linux. The problem occurs when
> boost::condition::notify_one() sometimes does not release the
> corresponding waiting thread. A second thread that depends on this
> release eventually becomes locked. The reason for this post is that
> I could not reproduce this behaviour using Windows threads with VC++
> 6.0 nor using pthreads in Suse 10.3 with g++ 4.2.1.
Your problem is that the waiting threads are checking mExec2 to see
whether or not to proceed, as part of the predicate loop around the
condition wait, but the updates to mExec2 in Exec2() and Release2()
are not done under protection of the mutex. You therefore have a race
condition, and it is possible that the waiting thread is not actually
waiting in the condition variable when notify is called, or it does
not see the changed value when it does wake, and waits again.
You don't need to hold a mutex during the call to notify_one(), but
you *do* need to hold a mutex to update the shared data. In this case
you need to be holding a lock on mMutex1 when you update mExec2.
There is no guarantee that this would work with POSIX condition
variables, so you are lucky if it does.
> I was in doubt if I should direct this post to a users list. I just
> could not find one specific for threads. My apologies in any case.
The main boost users list would have been the most appropriate place,
but it's not out of place here.
Anthony
-- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL