RE: [boost] Boost.Thread request: event object

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.

Sean