The FEE Server Control Engine of the ALICE-TRD - Westfälische ...

}
5 The FEEServer Control Engine
mcm_info [ s l ] . hopcount =
mcm_info [ s l ] . l i n k =0;
s l _ l e f t * 2 − s l −1;
}
i f ( s l >= s l _ r i g h t ) {
mcm_info [ s l ] . dest = no_of_slaves − s l +1;
mcm_info [ s l ] . hopcount = ( no_of_slaves−s l _ r i g h t ) * 2 − (
no_of_slaves−s l ) ;
mcm_info [ s l ] . l i n k =1;
}
broadcast_info . data [ 0 ] . hopcount_write= s l _ l e f t * 2 −1; / / l e f t
p a r t o f t h e l i n k p a i r
broadcast_info . data [ 1 ] . hopcount_write =( no_of_slaves − s l _ r i g h t )
* 2 +1; / / r i g h t p a r t o f t h e l i n k p a i r
Listing 5.3: Code to recalculate the slave IDs of the MCMs and the broadcast hopcounters in
case of a bridged linkpair. sl is the slave ID of the MCM in an unbridged linkpair,
no_of_slaves the total number of MCMs in the linkpair (34 or 36), sl_left the number
of MCMs in the ’left’ part and sl_right the number of MCMs in the ’right’ part of the
linkpair
When the calculation is finished the control flow returns to learnConfig() of SCSNBus. At
this point it is known which MCMs have to be bridged but the MCMs themselves are not
bridged yet. The function SCSNBus::learnConfig() calls * SCSNBusBridge::getSlavesToBridge
(void) for each linkpair to get the list of MCMs to bridge. In each linkpair either no, one,
or two MCMs have to be bridged. The function SCSNBus::learnConfig() creates the correct
SCSN commands and sends them to the MCMs (see next section). If no MCMs have to
be bridge this step is skipped.
Afterwards the configuration process is finished and the control flow returns to the
function which has called SCSNBus::learnConfig().
5.3.2 Access Synchronisation
In the FEEServer two threads run in parallel. One thread handles commands and configurations
received from the ICL and the other thread monitors the DCS board sensors and
the MCM temperature sensors.
At this point a problem occurs. The sensor readout in the second thread runs independently
of command handling thread but both threads need hardware access. Neither can
the SCSN bus be accessed by both threads at the same time nor is it possible to read out
the DCS board sensors and access the SCSN bus in parallel. To solve this problem the
mutex mechanism 6 is used.
In the control engine the mutex administration and the interface to open and close
the SCSN Bus are encapsulated in the class SCSNGuardian (libTRD). The constructor of
SCSNGuardian locks the mutex and opens the SCSN bus interface and the destructor unlocks
the mutex and closes the SCSN bus interface. Each time a thread needs SCSN bus
6 The mutex mechanism is a programming technique for inter-thread synchronization. One thread locks the
mutex as soon as it enters a function block which cannot run in parallel. If the other thread now tries to
lock the mutex because it also enters a function block which cannot run in parallel, this thread is stopped
as long as the mutex remains locked. When the mutex is now unlocked by the first thread the second
thread can lock the mutex and continues execution.
64