Boost Users :
Subject: Re: [Boost-users] condition_variable
From: Alessandro Bellina (abellina_at_[hidden])
Date: 2009-12-11 07:03:19
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)?
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)
> 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
> boost::mutex::scoped_lock lock(mutex);
> set some event which is been waiting thread1
> Maybe will be useful for you.
> Nikolai N Fetissov wrote:
> >> Thanks Nikolai,
> >> That explains why the second thread can lock that mutex. From what you
> >> saying then, the sleeping thread will wake up and reacquire the lock
> >> 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]
> > http://lists.boost.org/mailman/listinfo.cgi/boost-users
> Boost-users mailing list
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net