Dear all,
This message follows on from an original message from Philip Taylor to
tach-talk and a reply from Jeff Hill, both on July 8th. Philip asked
about queuing of monitored values in state programs and Jeff said that
he believed that they are not queued but are cached in a one-entry
cache.
I have an application where I have the same requirement as Philip:
namely to be able to change state on PV transitions from 0 to 1 and 1 to
0 where these transitions may be separated by a very short interval. I
can confirm that the logic on a monitor (proc_db_events() in seq_ca.c)
is:
1. copy the value (and other attributes: status, severity etc)
2. wake up any state sets which use this channel in a when() clause
3. if there's an associated event flag, set it (may wake up state sets)
Note that (3) above refers to the case where the "sync" statement has
been used to associate an event flag with a variable. Typically, a sync
statement such as:
sync fred efFred;
corresponds to a test such as:
when( efTestAndClear( efFred ) )
which checks whether any monitors have been posted on fred since the
last time that the test was executed.
I would like to propose a new form of the sync statement, perhaps
"syncQ", which will have the same syntax but the following behavior:
1. unlike sync, it will be an error to reference the same event flag in
multiple syncQ statements (it will also be an error to use both sync
and syncQ with the same variable)
2. on monitor, the value (and associated info) will always be added to a
queue and the event flag will be set; the sequencer variable value
will _not_ be updated at this point
3. a new pvGetQ() function will, if the flag is set, remove the oldest
item from the queue, copy it to the sequencer variable value, and, if
the queue is now empty, clear the flag
4. note that CA events are disabled while sequencer event functions
execute so there should be no race condition here
5. note also that it would be very useful (certainly in my application
and probably in general) if syncQ worked with arrays, which suggests,
I think, that there should be a single queue of values per array
rather than per array element (and each pvGetQ() will remove just a
single entry, which will correspond to one of the array elements)
6. perhaps the queue should have a specified maximum size to guard
against the case where no-one is calling pvGetQ()?
This is a new facility and is therefore an upwards compatible change.
I think it will be easy to implement although support for arrays seems
a little more complicated. I volunteer to do the work.
Are there any comments?
William
- Navigate by Date:
- Prev:
serial port Stefan Hippler
- Next:
Client from C-A to cdev Steve Lewis
- Index:
1994
1995
<1996>
1997
1998
1999
2000
2001
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:
- Prev:
serial port Stefan Hippler
- Next:
Client from C-A to cdev Steve Lewis
- Index:
1994
1995
<1996>
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|