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

_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users