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  <20102011  2012  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  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: monitors received out of order
From: Ralph Lange <[email protected]>
To: EPICS tech-talk <[email protected]>
Date: Mon, 01 Nov 2010 17:27:04 -0400
On 01.11.2010 17:09, Tim Mooney wrote:
Dear folks,

I have two records, and a separate task monitoring a field that both records
post, all in the same IOC. Most of the time, my task receives monitors in the
order in which they were posted. But sometimes, the task receives a monitor
from record B before it receives a previously posted monitor from record A.
(I know for sure which record is posting first, because record A posts before
causing record B to process. Also, I've modified the record to set its time
stamp immediately before posting, and I get another time stamp on entry to
the monitor routine. The time ordering of those stamps does not agree.)
I've seen this on solaris and Linux, but not on vxWorks.


I have code that misbehaves when this happens, so I started digging around
and have convinced myself that I should not be relying on the time ordering of
monitors received from different records (even when those records are running
in the same task). I now think I can rely on posts from a single record arriving in
time order, but not posts from different records. I think this because events from
different record go into different queues, and there doesn't seem to be any code
in the vicinity that seems worried about time ordering across event queues.


Am I right about this?

Short answer: yes.


The event queue is allocated in chunks. Each chunk has room for a number of subscriptions, and holds the values that are on the queue for these subscriptions.
The event task (per client) simply loops over the event queue chunks for this client (lines ~940 in dbEvent.c), and calls event_read() for each chunk, which loops over the queue entries in a chunk (line ~815) and pushes everything it finds there to the CA server (via user_sub, line ~865).
Depending on which subscriptions from which records are held in which event queue chunk, the order on the network may vary.


You are almost correct: The only order that you can rely on is the order of updates for a single subscription. (Two subscriptions for different fields of the same record may end up in different event queue chunks and get sent out-of-order.)

Ralph


Replies:
Re: monitors received out of order Tim Mooney
References:
monitors received out of order Tim Mooney

Navigate by Date:
Prev: monitors received out of order Tim Mooney
Next: RE: monitors received out of order Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: monitors received out of order Tim Mooney
Next: Re: monitors received out of order Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 09 Nov 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·