Boost logo

Boost :

From: Sean Kelly (sean_at_[hidden])
Date: 2004-01-24 19:00:00

On Sun, 25 Jan 2004, Matthew Hurd wrote:
> > On Behalf Of Sean Kelly
> >
> > The condition object is needlessly complex for instances where a thread
> > must wait on a signal but isn't immediately concerned with shared data.
> > Basically, I'd like a simplified version of condition that supports wait
> > and timed_wait without the predicate and without the need to pass a mutex.
> > It might be used like this:
> Needlessly complex is right. Inefficient is right.
> Do you think waiting on a mutex should also be modelled as an event?

Interesting idea. My initial feeling is that it should not. While the
semantics are similar, I think mutexes and events serve complimentary
purposes--one is a signalling mechanism and the other a synchronization
mechanism. For example, I can't imagine wanting to wait on multiple
events, some of which are mutexes. And timing out waiting on a mutex
seems to have different implications. Also, I can't work out a design in
my head that doesn't seem confusing to use.

I did just think of one way to model the timed wait method using the
existing lock structure though. Provide a conversion to bool that
indicates whether the mutex is locked or not. Combined with the recent
macro trickery from CUJ, the semantics could work something like this:

mutex mtx;
TIMED_WAIT( mtx, 1000 ) {

It would expand to this:

mutex mtx;

if( lock fancy_name_that_wont_collide( mtx, 1000 ) ) {

I can't think of an instance offhand where I'd actually use this, but I
imagine it might be useful in situations where a lock could be held for a
long period of time.


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