Subject: |
[Bug 668067] [NEW] documentation of libCom/osi/epicsEvent unclear |
From: |
Ben Franksen <[email protected]> |
To: |
[email protected] |
Date: |
Thu, 28 Oct 2010 22:10:26 -0000 |
Public bug reported:
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.
** Affects: epics-appdev
Importance: Undecided
Status: New
--
documentation of libCom/osi/epicsEvent unclear
https://bugs.launchpad.net/bugs/668067
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Application Developers'
Guide.
Status in EPICS Application Developers' Guide: New
Bug description:
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.
- Replies:
- [Bug 668067] [NEW] documentation of libCom/osi/epicsEvent unclear Ben Franksen
- [Bug 668067] Re: documentation of libCom/osi/epicsEvent unclear Andrew Johnson
- References:
- [Bug 668067] [NEW] documentation of libCom/osi/epicsEvent unclear Ben Franksen
- Navigate by Date:
- Prev:
Re: Error in creating the example application Andrew Johnson
- Next:
Re: epicsEvent Ralph Lange
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Next:
FW: StreamDevice bug nick.rees
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|