Re: monitors received out of order

[Ralph Lange <Ralph.Lange@bessy.de>]

 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