2.2 Stimuli to action; multi-threading

This page is part of the ING document INS-DAS-31 Design notes for UltraDAS

Cases in which udas_camera takes action

Udas_camera initiates action only in three cases:

When the programme is started up.
In response to a DRAMA message.
On the expiry of certain timers.

There are no actions in direct response to other external events, not even drastic changes in state of the camera, because udas_camera is not directly sensitive to these changes. Instead, udas_camera detects events in the environment, and particularly in the camera, by polling, and the polling operations account for all the timer-based stimuli. For example, the programme polls at 1Hz for shutter state during and exposure, and once per minute at all times for cryostat temperature. This formalism is largely dictated by the bahaviour of the hardware interface to the camera (the interface does not allow the camera controller to send messages to the camera server unless the camera server asks for data), but has also been exploited to simplify the overall problem; udas_camera does not need to deal with signals and interrupts, for example.

The start-up processing is concerned firstly with setting up the Fixed Plant objects that the programme uses (q.v. the Fixed Plant pattern) and with restarting and programming the detector controllers. This processing is purely sequential.

The vast majority of stimuli are obey commands for DRAMA actions (see the notes on the DRAMA Facade for a discussion of the actions). Once started, each action runs to completion unless it fails or is cancelled by a DRAMA kick command. However, the actions are chosen to make a neat interface for the client software, not for ease of implementation in the server. This means that long-running actions (e.g. an action running a 30-second readout and and action saving the previous readout laboriously to disc) must overlap in time and must run in quasi-parallel on the uni-processor computer. This introduces multi-threading to the design, as discussed below.

Often, the timers in the telemetry-polling loops expire while an action is active. Telemetry must be (moderately) timely, so the telemetry processing also has to run in parallel with the actions.

Use of threads to separate stimulus-action sequences

Many actions take a long time to complete. The longest is the INTEGRATE action, which runs an exposure or integration and could last an hour or more. The actions inevitably overlap, and some means is required to separate the contexts of the actions running in parallel.

Udas_camera uses Pthreads to separate the contexts. Each action causes one worker thread to be started, following the Casual Worker pattern (q.v.). The telemetry-polling loops run in other worker threads that belong to the Fixed Plant objects and follow the Tenured Worker pattern (q.v.). This allows each stimulus-action pair to run to completion, while sharing the single processor in the DAS computer.

Some action threads start a further layer of Casual Worker threads; the RUN, PROCESS and ARCHIVE actions do this. This allows these actions to firstly process in parallel with blocking I/O and secondly to make periodic telemetry reports to the facade on what they have acheived. In these cases, the second-generation Casual Workers must all finish and be "payed off" before the first-generation worker can finish.

The worker threads are scheduled by the Solaris kernel (they are system-scope threads) using a timeslicing algorithm, and this gives an adequate response to all soft-real-time operations. Where a hard-real-time response is needed, the worker thread is scheduled, again by the Solaris kernel, in the RT class, and this gives it priority over all the timesliced threads. The dispatch latency in Solaris for this scheduling class is stated by SUN to be bounded, but no bounding value has been quoted for modern SUN computers. The worst-possible latency is believed to be around 0.2ms (the published figures for an old SPARCstation 5 are better than this), and this has proven fast enough for all udas_camera's needs. Udas_camera has never been shown to fail in service due to over-running a time-window for hard-real-time I/O.

Because of the threading, most of the