RFC: Multithreading design constraints

From: scleary_at_[hidden]
Date: 2000-06-07 07:15:58

>   Event - Either signalled or unsignalled.  Any thread may set the state
to
> signalled.  Any thread may set the state to unsignalled.  Any thread may
> wait for the state to become signalled, which will block until the state
is
> signalled.
>   Gate - Either open or closed.  Any thread may open the gate.  Any thread
> may close the gate.  Any thread may wait for the gate to open, which will
> block until the gate is open.  Any thread may atomically open and close
the
> gate, releasing any waiting threads.
> 
> I'm not too clear what the difference between these is, as Opening the 
> gate alone will release those threads that were waiting when you started 
> opening the gate, and any others that make it there before you close the 
> gate again. Is 'open and close' an atomic operation that will not allow 
> any threads that were not blocking when the decision was made to open the 
> gate to join the waiting queue?  If so, why?  If not, then why can't you 
> just use an event? What does 'automatically' mean?

It's 'atomically' -- I don't know if it's a word or not, but it means 'in an
atomic way'.  In my post, Event, Gate, and Condition are very similar.  A
Gate is an Event + an atomic open&shut operation.  A Gate is also a
Condition + the ability to stay open (Conditions may only open&shut
atomically).

We may just drop Event, since Gate does that and more, but we should keep
Condition because there are matching OS primitives already available on
POSIX systems.

        -Steve