How the system is threaded

How the system is threaded

The readout software is a highly threaded system. Threading is used to allow the software to cleanly expect and respond to several types of external stimulii.

The threading is done on top of the NSCL DAQ programming framework. The program framework supports separate threads for each stimulus a program may wait for. The threads autonomously wait for a simulus and, when one is recieved, acquire a single global synchronization mutex. This has the effect of simulating an open ended event based programming system within the context of multithreading.

In addition to a standard set of event types, the program framework supports the concept of guest event processing frameworks. Tcl or Tk run as a guest event processing framework. In handling the Tcl interpreter, the assumption is that most Tcl commands (e.g. set) dont' require synchronization. Extensions to the base interpreter are derived from a CDAQTCLProcessor which acquires the syncronization mutex prior to transferring control to the object's operator().

If scripts require synchronization, the Tcl interpreters also support the sync command. The sync command takes a single argument, which is a script that is executed with the global mutex held.

The global mutex is a counting mutex, so there's no penalty to acquire it several times within a single thread, however you must release the mutex the same number of times it has been acquired.

The code example below shows how to use the global syncronization mutex in your code if you work outside the limits of the program framework:

      #include <SpectroFramework.h>
      ...
      
      // Unsynchronized.
      
      CApplicationSerializer::getInstance()->Lock() 
      
      // this code is synchronized.
      
      CApplicationSerializer::getInstance()->UnLock();
      
      // Unsyncrhonized
      

The figure below shows the start/stop relationships between the threads of the system:

• The main thread starts off the Tcl interpreter and enters a sleep loop periodically checking a flag that is set when the application should exit. When the application should exit, the main process executes the exit(2) system service, which ends all threads.
• The Tcl interpreter thread, on startup determines if TclServer functionality has been requested. If so, the serverauth command is registered and a CTCLListener object is creaeted and run in its own thread.
• The CTCLListener thread listens for connections on the specified Tcp/Ip port. When a connection is honored, a CTCLServer object is started and run in its own thread. The CTCLServer object accepts commands from the client and executes them until the client exits. All client scripts are serialized with respect to each other and also run with the global serialization mutex enabled, however, they will not be synchronized with respect to scripts and commands executed in the main Tcl/Tk thread, unless those scripts and commands are run within the sync command.
• The Tcl/Tk thread, in response to a begin command e.g. will start off two threads. The Trigger thread watches for event triggers and, in response to them, reads out events from the hardware. The Clock thread keeps track of elapsed run time and triggers scaler readouts. The Tcl/Tk also kills these threads in response to commands (end, pause) that deactivate the run. Since these commands run synchronized with respect to both the trigger and clock thread, there's no danger the trigger thread or clock thread are asked to terminate in mid event.

How the system is threaded