Threads: condition::timed_wait

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2001-10-11 15:40:10

Hi boosters,

Summary question: Why does boost::condition::timed_wait require a 
ScopedTimedLock in its implementation? It doesn't appear that the 
ScopedTimedLock properties are necessary to the timed wait itself...

Background:
I'm trying to do a simplistic thread-cancellation model without thread 
cancellation in boost::Threads. I have a thread which I want to wake up 
periodically, process requests which have accumulated, and then go back 
to sleep. (There are reasons for not wanting continuous processing, but 
I won't go into that).

However, if the parent thread is dying, I want this child thread to be 
signalled, wake up before its time, process any last requests, and then 
exit. So I implemented this with a loop:

  bool done = false;
  while(!done) {
      boost::xtime xt;
      xtime_get(&xt,boost::TIME_UTC);
      xt.sec += transmission_delay;
      boost::timed_mutex::scoped_timed_lock 
        termination_lock(pimpl->termination_mutex, true);
      pimpl->termination_condition.timed_wait(termination_lock, xt);
      done = terminate;

    // Do other processing...

  }

Where terminate will be set by another procedure locking then releasing 
the termination mutex.

My question is: why do I need to use a timed_mutex and 
scoped_timed_lock in this case? I'm not going to have the lock expire, 
just the wait. And this makes me put this 'true' parameter in there 
which is rather non-transparent, shall we say...

Not that it's really HARD to do, I'm just curious as to whether there's 
something more subtle being done inside timed_wait, or whether 
restrictions could be loosened.

George Heintzelman