Boost logo

Boost Users :

Subject: Re: [Boost-users] condition_variable
From: Adam Szeliga (aszeliga.xsoftware_at_[hidden])
Date: 2009-12-10 17:11:08

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 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]

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at