EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: epicsEvent (posix implementation) bug ?
From: Till Straumann <[email protected]>
To: [email protected]
Date: Mon, 31 Jan 2011 11:48:11 -0600
On 01/31/2011 11:28 AM, Eric Norum wrote:
This topic seems to have shifted a little.

Yes. Note that I had created a new subject for the epicsEvent
semantics issue. (but got confused by james.rowland's message
which probably was posted to the wrong thread).

It started out as discussing the semantics of epicsMessageQueue with
multiple readers. The shift to the semantics of epicsEvent with multiple
waiters is a result of the POSIX implementation of epicsMessageQueue.
I think that both issues are worthy of discussion and that there's
likely more than one place in the appDevGuide that could use such a
statement.

FWIW, both vxWorks and RTEMS currently provide FIFO semantics for both
epicsMessageQueue with multiple readers and epicsEvent with multiple
waiters.....

Currently, the posix epicsMessageQueue implements FIFO semantics and
the posix epicsEvent implements highest-priority first semantics.

The proposed changes to posix epicsMessageQueue implementation would
switch it to highest-priority first semantics but allow for considerable
simplification.

T.


On Jan 31, 2011, at 9:09 AM, Jeff Hill wrote:

ØNot sure about windows, but since priority inversion is a major issue
only for
Øsystems with strict priority-based scheduling I'm not sure that it's
that big a
Ødeal there anyhow.
So I can confirm that Windows does not support such options, and agree
that this is probably because it isn’t that type of (strict priority
scheduled) OS. I am going to guess that Windows CE also doesn’t allow
for such options.
Perhaps the application developers guide should say something like this.
“Where possible and reasonably efficient the OS specific
implementation of the event semaphore should select options which
provide priority based queuing, but portable source codes who are
consumers of theepicsEventinterface should not depend of this feature
nor allow its absence to substantially change their run-time behavior.”

--
Eric Norum
[email protected] <mailto:[email protected]>



References:
epicsEvent (posix implementation) bug ? Till Straumann
RE: epicsEvent (posix implementation) bug ? james.rowland
Re: epicsEvent (posix implementation) bug ? Eric Norum
RE: epicsEvent (posix implementation) bug ? Jeff Hill
Re: epicsEvent (posix implementation) bug ? Eric Norum

Navigate by Date:
Prev: Re: epicsEvent (posix implementation) bug ? Till Straumann
Next: RE: epicsEvent (posix implementation) bug ? james.rowland
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: epicsEvent (posix implementation) bug ? Eric Norum
Next: RE: epicsEvent (posix implementation) bug ? james.rowland
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·