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

From: matt_at_[hidden]
Date: 2004-01-24 21:27:40

> On Behalf Of Sean Kelly
> Subject: RE: [boost] Boost.Thread request: event object
>
> > > 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.

Signalling and synchronisation could be the same thing.

Multiple events, mutexes / events, could be required for any kind of
transaction where multiple resources are required.  Makes sense to me to
have the same model.  Transactions could involve physical resources with
events, such as a socket io and file io, and possibly resources that are
shared and thus require mutexes.

You could also allow platform dependent optimisation for the wait for
multiple objects case with a bit of MPL magic perhaps.

A reactor model with timers etal would be a natural with such a base in
place.

This makes the most sense to me as a model for sockets, file io, mutexes,
timers or other signals.  On win32 other signals includes:  change
notifications, console input, jobs, and memory resource notifications
beside the usual synch primitives:  events, mutexes, semaphores, threads
and waitable timers.

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

I think this gets you the same affect as the code you wrote above with the
current boost::thread lib FWIW...

        typedef boost::timed_mutex::scoped_timed_lock lock;
        boost::timed_mutex guard_;

        //...

        {
                lock lk(guard_, false);
                if (  lk.timed_lock(t)  )
                {
                        // do it
                }
        }

An evil macro would make it shorter, yep.

Regards,

Matt Hurd