Experimental Physics and
Industrial Control System

[email protected] (William Lupton) · Mon, 22 Jul 96 17:26:27 HST

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System