Re: [Boost-users] condition_variable

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)
    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]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>