FSM (Finite State Machine)

We propose to use a two-phase approach for each transition in the DRP FSM, inspired by the LCLS-I approach

• The first phase is handled by a ZMQ broadcast, so configures can happen in parallel
• The second phase is handled in the timing system thread.  This phase "sweeps" out the results from the first phase
• The control level sends out both phases immediately
• The FSM runs in the ZMQ thread, except for event(), which runs in the timing system thread
• All other code in the timing-system thread (apart from event()) should not be detector-specific
• The timing system thread is responsible for all xtc writing
• If a DRP has N workers, only one of them will receive the timing system transition
• The completion of the first phase of the transition is "hidden" from the control level (i.e. it only sees the completion of the second phase)
• For each non-event transition:
  • the timing thread waits for a result from the ZMQ thread, with optional JSON that should be appended to the output xtc
  • each transition (maybe just configure and configUpdate) specifies a timeout value, perhaps with the CONNECT collection message
  • timeouts are used by
    • the timing-system thread to wait for the message from the corresponding ZMQ thread
    • the control level to timeout the responses from the various DRP timing system threads.  we believe the control level can set the value to the maximum of all the timeout values

In this diagram the ZMQ threads are on the left and the timing system (TS) threads are on the right.

• "SegWork" is a segment-level worker thread (one of many)
• "Eb" corresponds to the infiniband event-builder
• "EbRcvr" corresponds to the thread in the DRP node that receives the dgram response from the Eb.