event ordering

["Jeff Hill" <johill@lanl.gov>]

Hi Nick,

I placed this comment in the white board on your blueprint at launchpad. 

An event queue with substantially better behavior (than my original
dbEvent.c) is implemented on the cvs trunk (see
lp:~epics-core/epics-base/cvs-trunk ). See also
https://blueprints.launchpad.net/epics-base/+spec/ca-server-upgrade.
However, recall that, given elementary queuing theory, in situations where
the producer is faster than the consumer we do have to throw out a less
recent (than the current) update for a fast updating subscription if we will
not use up all remaining memory. To make certain that the most recent update
is always sent I have a list of subscriptions that are temporarily in
overflow state. I do currently allow subscription updates for subscriptions
that are not in overflow state to continue to be placed on the queue when
others are in overflow so this could cause the cached  update of
subscription overflow update X to be out of order (in their timestamps) wrt
slow subscription update Y when the queue reading thread gets to run and it
takes care of the updates for the overflow events. I suppose that this could
be fixed by forcing the overflow updates to be obtained with a forced get
instead of from a cache of the last update so that their timestamp will
reflect the current time, but this would involve some additional overhead.

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