
Thanks Nikolai, That explains why the second thread can lock that mutex. From what you are saying then, the sleeping thread will wake up and reacquire the lock after notify is called. So the thread that calls notify should not hold that lock when this happens or you could have deadlock right?. Alessandro On Thu, Dec 10, 2009 at 12:25 PM, Nikolai N Fetissov < nikolai-boost@fetissov.org> wrote:
Why is it that since we already hold a mutex in the requesting thread,
the
thread handling the response can successfully lock that mutex too? Does the condition.wait call set something in the lock?
Thanks,
Alessandro
The idea of wait on a condition variable is to atomically release the mutex and enter some sort of sleep mode, which is later interrupted by a wake-up from a different thread. At that point the mutex is re-aquired. So, yes, condition.wait() unlocks the mutex and waits for notification, then locks the mutex again.
-- Nikolai
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users