Spurious wake ups?
Thanks for posting your example. I don't really know why we need to set
"some_event_occurred". Is this the recommended usage?
Other than your first iteration (where you need the flag, but that is
because you are using a do/while as opposed to a while loop), are we
supposed to get spurious wake ups (i.e. will timed_wait return true even if
we didn't call notify_one)?
Alessandro
On Thu, Dec 10, 2009 at 4:11 PM, Adam Szeliga
This is scheme which I often use:
// Common for both threads boost::mutex mutex; boost::condition condition;
// Thread1:
boost::xtime waitingTime(set value of waiting time) {
boost::mutex::scoped_lock lock(mutex) do { if (some_event occurred) { do something after received event return; // exit point after receive event } } while (condition.timed_wait(lock, waitingTime)); do something after timeout occurred // exit point after timeout }
//Thread2
{ boost::mutex::scoped_lock lock(mutex); set some event which is been waiting thread1 condition.notify_one(); }
Maybe will be useful for you. Adam
Nikolai N Fetissov wrote:
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,
The thread calling the 'notify' can, but does not have to, hold a mutex at the time. In theory all the notify() function does is mark the thread sleeping on the condition as runnable. There's no deadlock here. Also google for 'spurious wakeup' to get a firm hold on mutex/cv concepts.
Cheers, -- Nikolai
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users