From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2001-10-11 15:40:10
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;
xt.sec += transmission_delay;
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk