Re: monitors received out of order

[Kate Feng <feng1@bnl.gov>]

Hi Tim and Jeff,

   Linux and Solaris are not real-time operating systems to ensure the 
order
of the events, unless there is a real-time extension (e.g. real-time Linux).
Another option is to rewrite the application code to ensure the order of 
events.
The code written for vxWorks usually relies on O.S. to ensure the order.
For a non real-time O.S., one would have to write extra code at the user
application level to ensure the order. If one uses EPICS, then EPICS
is considered as part of the application levels.

Cheers,
Kate

Jeff Hill wrote:
> Hi Tim,
>
> The Channel Access publish and subscribe system is a classic
> consumer/producer situation. The producer is of course record
> processing and the consumer is the Channel Access client side 
> application. In basic queuing theory, it is known that no
> matter how big the finite buffer capacity between the producer
> and the consumer, all of it will be consumed if the production
> rate is even a marginal amount faster than the consumption rate.
> Furthermore, to prevent one client from disrupting subscription 
> updates sent to another client, each client attaching to an IOC 
> is serviced out of a per-client dedicated event queue connecting 
> the higher priority database processing threads with the lower
> priority per-client server threads. So to avoid consuming all
> available memory this event queue is finite length, and if full
> capacity is reached the last event on the queue for a particular
> subscription is replaced; this has the net impact of causing an 
> intermediate subscription update to be discarded.
>
> So one can easily see, given the above design with intermediate 
> events being discarded when the producer out-paces the consumer,
> that events will sometimes be delivered out of order when comparing
> different channel subscriptions, but that events will never be 
> delivered out of order within a single channel subscription.
>
> HTH
>
> Jeff
> ______________________________________________________
> Jeffrey O. Hill           Email        johill@lanl.gov
> LANL MS H820              Voice        505 665 1831
> Los Alamos NM 87545 USA   FAX          505 665 5107
>
> Message content: TSPA
>
> With sufficient thrust, pigs fly just fine. However, this is
> not necessarily a good idea. It is hard to be sure where they
> are going to land, and it could be dangerous sitting under them
> as they fly overhead. -- RFC 1925
>
>
>   
> > -----Original Message-----
> > From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov]
> > On Behalf Of Tim Mooney
> > Sent: Monday, November 01, 2010 3:10 PM
> > To: EPICS tech-talk
> > Subject: monitors received out of order
> >
> > 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?
> >
> > --
> > Tim Mooney (mooney@aps.anl.gov) (630)252-5417
> > Software Services Group, Advanced Photon Source, Argonne National Lab.
> >     
>
>
>