Re: [Boost-users] condition_variable

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://lists.boost.org/mailman/listinfo.cgi/boost-users
>     >
>
>     _______________________________________________
>     Boost-users mailing list
>     Boost-users_at_[hidden] <mailto:Boost-users_at_[hidden]>
>     http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users