Boost logo

Boost :

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

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;
      xt.sec += transmission_delay;
        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

Boost list run by bdawes at, gregod at, cpdaniel at, john at