Re: [Boost-users] condition_variable

- Yes you are right, loop is needed due to spurious wake ups. - timed_wait return true if condition is notified or due to spurious wake ups. We need additional variable for distinguish that. - The flag some_event_occurred is needed in case where conditional.notify_one is called just before calling conditional.timed_wait. Example without flag some_event_occurred: thread 2 -> lock mutex thread 1 -> hold on mutex thread 2 -> condition.notify_one() thread 2 -> unlock mutex thread 1 -> lock mutex thread 1-> hold on condition.timed_wait and waiting up to timeout occurred In this example notify_one "is missing" by thread1 If is it still unclear, please ask more. Regards Adam Alessandro Bellina wrote:

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 mailto:aszeliga.xsoftware@gmail.com> wrote:

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 mailto:Boost-users@lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org mailto: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