V4 Design: Record Processing
EPICS V4: Record Processing
June 22 2005
Overview
NOTE: Preliminary thoughts.
This document describes how records are processed.
The record processing model is different than the V3 model.
The model consists of the following features:
- provides synchronous and asynchronous record processing
- provides callbacks when an asynchronous record completes processing
- provides alarms
- provides posting of modifications
The asynchronous processing model is designed so that both control and data acquisition database applications can be implemented. Data acquisition applications need a way to delay record processing until linked records complete processing. In V3 several special record types, in particular the wait record, were created to do the waiting. The V4 asynchronous processing model supports data acquisition applications without requiring special record types.
Synchronous vs Asynchronous processing
Each record instance is either synchronous, i.e. it will not block during
record processing, or it is asynchronous, i.e. it can block.
It is the responsibility of record support and associated link or device support to declare if a record instance is asynchronous. A field in dbCommon states if the record is asynchronous.
If a record is synchronous than the record is processed via normal scan threads. For example if the record is periodically scanned than it is processed by a periodic scan thread.
A pool of threads are provided to process asynchronous records. The maximum number of threads in the pool is configurable.
A pool has an associated queue of records to process. When a process request is received it is assigned to a thread with the shortest queue, ideally one with an empty queue.
An asynchronous record is allowed to block.
The rest of this section describes additional features related to asynchronous processing.
Notification of Process Completion
The request to process an asynchronous record can specify a callback that is called when the record completes processing. It is also possible to make a process callback request over the network.
Wait for intermediate results
A record instance has an associated list of epicsEvents. Instead of blocking, link and or device support can add an epicsEvent to the list. Record support can make a call to wait for all events on the list before proceding.
As an example the calcOut record could do the following:
- call the link support for each input link. Any link support that makes an asynchrous request to obtain data adds an entry to the event list.
- after all the input link support has been called, record support waits for all the events to be signaled.
- record support does the calculation and puts the result in the value field.
- record support calls the support for the output link. If the output link makes an asynchronous call it adds a entry to the event list.
- record support waits for the event before completing record processing.
flavors of link support
Link support for database and/or channel access links should support the following:
- get
- get value
- process first then get data
- put
- put only
- put and request processing
- put, request processing, and wait for completion
Alarm Processing
Are changes needed from the V3 model?
Posting Modifications
Whenever code modifies a field that is acessable outside the record it must call ????
When record support wants the modifications to be made available to code that has set monitors on fields in the record it calls ???
