Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  Index 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018 
<== Date ==> <== Thread ==>

Subject: Re: epicsEvent
From: Ralph Lange <Ralph.Lange@bessy.de>
To: tech-talk@aps.anl.gov
Cc: EPICS Core Talk <core-talk@aps.anl.gov>
Date: Thu, 28 Oct 2010 18:39:48 -0400
The RTEMS implementation does a "wake up one", consistent with the other implementations.

Maybe the current set of OSI primitives is not sufficient?

I definitely see Benjamin's point, and having a "wake up all" in addition to the current "wake up one", and/or making the "wake up one" configurable to select FIFO or priority behaviour could be useful.

~Ralph
ps. Let's move this thread to core-talk.


On 28.10.2010 18:31, Till Straumann wrote:
In RTEMS you can 'flush' a semaphore which releases all blocked threads
(they will get a special error return code indicating that they
do not 'hold/own' the semaphore buill that's fine for synchronization).

However, I don't know if the RTEMS implementation uses this feature.

== Till

On 10/28/2010 04: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


Replies:
Re: epicsEvent Ben Franksen

Navigate by Date:
Prev: [Bug 668067] [NEW] documentation of libCom/osi/epicsEvent unclear Ben Franksen
Next: Re: epicsEvent Ben Franksen
Index: 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018 
Navigate by Thread:
Prev: Re: Error in creating the example application Andrew Johnson
Next: Re: epicsEvent Ben Franksen
Index: 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·