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

From: Sean Kelly (sean_at_[hidden])
Date: 2004-01-25 16:16:54

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

Good point.  I was thinking about this after I sent my last email.  But
part of me is still concerned that such a design could lead to a deadlock
(ala the dining philosopher problem).  I think if there were a time where
I needed to acquire multiple resources for an operation I would probably
manage access to those resources through a single object which might fire
an event or return a handle when access was available.  Even so, I'm not
sure that this concern is enough to discount the design altogether.
I'm kind of warming up to the idea of mutexes as events.

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

So how would you suggest handing the calling semantics?  Would it be
assumed that if a mutex wait operation returned true that the lock was
acquired and false if it timed out?  ie.

if( mutex_event.wait( 1000 ) ) {
   ...
   mutex_event.unlock();
}

Sean