Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 28 Oct 2010 16:32:53 -0600

On WIN32:

http://msdn.microsoft.com/en-us/library/ms682396%28VS.85%29.aspx

"When the state of an auto-reset event object is signaled, it remains
signaled until a single waiting thread is released; the system then
automatically resets the state to nonsignaled. If no threads are waiting,
the event object's state remains signaled."

I suppose that the only issue with being more specific about behavior will
be encountering a new os where that behavior is inefficient to reproduce.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Eric Norum
> Sent: Thursday, October 28, 2010 3:44 PM
> To: Ben Franksen
> Cc: EPICS Techtalk
> Subject: Re: epicsEvent
> 
> Well, the vxWorks and RTEMS implementations of epicsEvent use simple
> binary semaphores.  The POSIX implementation also looks like it will also
> provide the semantics of a simple binary semaphore.   The WIN32 version I
> have no idea about.
> Assuming that the WIN32 does provide the desired semantics maybe we should
> update the documentation to state that this is how epicsEvents are to
> work.
> 
> On Oct 28, 2010, at 2:30 PM, Ben Franksen wrote:
> 
> > The documentation of libCom/osi/epicsEvent in the Developer's Guide
> > carefully avoids saying anything about what happens if an event gets
> > signalled and more than one thread waits for the event to happen.
> >
> > The name "event" and most of what's written in the docs suggest that
> > *any* thread waiting for an event will be able to continue as soon as
> > the event gets signalled.
> >
> > If this is true, how do I get the effect of a (binary) semaphore, i.e.
> > only one thread waiting on the semaphore will continue, the others have
> > to wait until the semaphore is given again?
> >
> > Or, if it is false, i.e. epicsEvent really acts like a binary semaphore,
> > I suggest that this be more clearly stated in the docs. It should also
> > be stated how the library or system choses the thread to run; in
> > VxWorks, this can be influenced when creating the semaphore (FIFO or
> > priority based), but if other systems do not allow such a distinction
> > then it should be explicitly stated in the documentation that no
> > assumptions should be made about which thread is chosen. Note that this
> > severely complicates things if you want e.g. FIFO semantics, because
> > you'd have to implement all the queueing yourself.
> >
> > Thanks
> > Ben
> 
> --
> Eric Norum
> [email protected]
> 
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System