level2QueManager State Diagram


Click on the image for a postscript file.....


Essentially the Level 2 Que Manager functions in the same way as the Level 1 Que Manager. Upon initialization the Level 2 Que Manager checks the Level 1 Accept Que for a L1 triggered event. Upon receipt of a good event it determines whether there is an event being loaded to a L2CPU. If a CPU is being loaded the event remains in the L1 Accept Que until LOADING=FALSE. The event is then removed from the Level 1 Accept Que and a L2CPU is selected.

For Level 2 the CPU selection is made based on CPU activity, the QueManager utilizes the first open CPU. It searches through the Level 2 CPU's in the L2CpuFarm. If all the processors are busy it looks for the least filled L2CpuMemQue and places the event there. If all the L2CpuMemQue's become filled and the QueManager attempts to load an event a FATAL error is set so that events which lead to this state can be examined.

Again the load time is fixed with no distribution. The value currently utilized for Level 2 is 100 microseconds. When loading the CPU the QueManager broadcasts to the EMC/TOF to receive its information. If the selected event is not available the Queue Manager WAITS until the event arrives at its respective memory location. The WAIT can be longer than 100 microseconds, although this is flagged to ensure the long WAIT is not a nasty BUG!

The second primary function of the object is to check the results from the L2CPU analysis. The object looks at the L2ResultQue. Upon finding an event the QueManager updates the trigActionWord and broadcasts the results to the trigInterface . The broadcast has a WAIT period of 10 microsends which represents delay in transmitting the information from the counting house back to the detector.

If the event is accepted at Level 2, it is placed in the level2AcceptQue .

Back to the Object Model .
J.P. Whitfield, Carnegie Mellon 4/20/95