Reimplement event queue to ensure events are delivered in the order they are generated

Registered by Nick Rees

Modify the event queue code so that it delivers events in the order they are generated. At present they are delivered mostly in that order, but because the event queue is chunked some events are delivered out of order. There may be some complications, because this doesn't neccesarily explain why VxWorks events seem better at being delivered in order than non RTOS events.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
Accepted for 3.15
Implementation:
Implemented
Milestone target:
milestone icon 3.15.branch
Started by
Ralph Lange
Completed by
Ralph Lange

Sprints

Whiteboard

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.

I was thinking about this last night on the way home and there is a design trade off. If you use a doubly linked list data structure then one can remove an event for a fast subscription from the middle of the list, but this requires more bytes per event entry and possibly more overhead for allocating and constructing an event entry. The portable server uses a doubly linked list and individually allocated objects for its event queue entries as I recall.

With the introduction of server-side-plugins, the event queue updates (called field logs) were changed from the chunked, static to an allocated, accessed-by-pointer (free-list based) implementation.
As a side effect, updates are now sent in order.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.