Ao pdev software.

30may07

  

Contents

   

Overview:

What was changed in jeff's design  

         I changed the design to: pnet -> prun -> psrv -> sharedMemoryBuffers --> bpInp --> shareDMemory -> bpOut -> disc/socket/etc..
    
I made the following modifications to psrv:

The buffering system:

    The datataking uses a large block of shared memory to buffer the input data. Two sets of fixed length buffers are allocated: large buffers of 20 Mb each and small buffers of 4kb each. Queues (linked lists in shared memory) are used to keep track of the free buffers, and various stages of processing. Programs request  a free buffer from the free list, fill/process the buffer, and then place the buffer on the next queue for processing. When done the with a buffer, it will be put back on the free list.
    Buffers can hold data (usually the large buffers) or commands for the program (the small buffers). The data processing is queued with a possibly large pipeline delay. Commands to a program go thru the same queueing system as the data buffers to insure that the commands are  executed in the correct order.
    The buffers system is centered around a Node. There is 1 node for each buffer in the system. The first part of each node contains pointers that can be used to link the node into a linked list. Nodes also contain some space to specify what they contain (data, header, command, etc..). The final elements are the pointers to the buffer for this node. The node to buffer mapping is setup by bufpoolD at boot time and does not change. The pointers/addressing are done using offsets from the start of shared memory rather than absolute addresses since different processes can map shared memory into their local address space at different locations. The routines make the addressing transparent to the user (when you want it, you get a ptr to the buffer).

  Communications:

     The ao programs will be multi threaded. One thread will wait on the input queue for that program. When a buffer becomes available, it will process it and then pass it on to the next step. Once a second this thread will wake up to see if there is anything else to do. A second thread will wait on communications from the outside world (probably a tcp socket?). When a request arrives (say from the gui)  it will process it and probably place it on the input queue for the first program. This guarantees that the commands are executed in the correct order.
    Some things that need to be worked out with the queueing system are:
  1. When a command gets processed from a queue, there may need to be a reply going back somewhere. This requires some type of address in the queued command for the reply.

The current list of programs:

The Queues in shared memory:


The program details:

Psrv

bpInp 

bpOut:



<- page up

home_~phil