Experimental Physics and
Industrial Control System

Tim Mooney <[email protected]> · Thu, 5 Jul 2012 12:18:45 -0500 (CDT)

Dirk,
Yes, there is a mechanism in EPICS that can cause monitors to be acted on out of order.  I found this happening with saveData on Linux.  There's a long tech-talk thread on the subject "monitors received out of order" from around November 2010.  Basically, the problem is that monitors go into event-queue blocks that are arranged according to the order in which the PVs were subscribed to, but the event task runs through the blocks in order.  Monitors are time ordered within a block, but not among them.  If the event task doesn't run promptly enough, monitors get acted on out of order.
Tim

----- Original Message -----
From: "Dirk Zimoch" <[email protected]>
To: "EPICS" <[email protected]>
Sent: Thursday, July 5, 2012 10:21:55 AM
Subject: Question about CA event (i.e. monitor) time order

Hello,

Consider a client that subscribes for two PVs (here in particular two 
fields of the same record). Now the IOC (the record support) posts 
events on both fields. Is the time order of these two events preserved?

In other words, are the monitor callbacks of the client called in the 
same order as the IOC calls db_post_events()?

In my particular case, I have a client (with unknown source code) that 
sometimes sees value changes on two fields of the motor record, DMOV and 
RRBV, in the wrong order. Thus in the DMOV callback, RRBV still has the 
old value. I checked in the motor record that DMOV is always posted 
after RRBV.

Is there any mechanism in EPICS that could swap the execution order or 
should the problem be searched in the client?

Dirk

-- 
Tim Mooney ([email protected]) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System