Subject: Re: [Boost-users] condition_variable
From: Adam Szeliga (aszeliga.xsoftware_at_[hidden])
Date: 2009-12-11 15:48:13
- 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
> <aszeliga.xsoftware_at_[hidden] <mailto:aszeliga.xsoftware_at_[hidden]>>
> 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_at_[hidden] <mailto:Boost-users_at_[hidden]>
> > http://listarchives.boost.org/mailman/listinfo.cgi/boost-users
> >
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden] <mailto:Boost-users_at_[hidden]>
> http://listarchives.boost.org/mailman/listinfo.cgi/boost-users
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://listarchives.boost.org/mailman/listinfo.cgi/boost-users