A REAL-TIME
PROGRAMMING
H. R. A.
SYSTEM
TOWNSEND
Regional Clinical Neurophysiology Service, Western General Hospital, Crewe Road, Edinburgh EH4 2XU (Great Britain)
(Received: 15 May, 1978)
SUMMARY
The paper describes a Basic Operating and Scheduling System (BOSS) designed for a small computer. User programs are organised as self-contained modular ‘processes’ and the way in which the scheduler divides the time of the computer equally between them, while arranging for any process which has to respond to an interrupt from a peripheral device to be given the necessary priority, is described in detail. Next the procedures provided by the operating system to organise communication between processes are described, and how they are used to construct dynamically self-modifying real-time systems. Finally, the general philosophy of BOSS and applications to a multi-processor assembly are discussed.
SOMMAIRE
On decrit dans cet article un Systeme de Base Optrateur et Rt-partiteur (sigle anglais BOSS) concu pour un petit calculateur. Les programmes sont organist% comme des ‘processus’ modulaires independants et l’on akrit en &tail la faGon dent le temps du calculateur est reparti de faGon &gale entre ceux-ci, la priorite restant neanmoins donnte a tout processus akvant mtervenir a la suite dune interruption provenant dun disposittfptriphkique. On decrit ensuite les procedes oflerts par le systeme pour organiser les relations entre les processus ainsi que la maniere dent ils sont utilises pour construire des systemes en temps reel se modtjant dynamiquement eux-mcmes. Pour$nir on discute de la philosophie generale de BOSS et de ses applications d un montage multi-processeur. 129
ht. J. Bio-Medical Computing (10) (1979) 129-143 @Elsevier/North-Holland
Scientific Publishers Ltd.
130
H. R. A. TOWNSEND
INTRODUCTION
This paper describes an operating system designed for a small computer (GEC 2050) which is used for routine analysis of EEG records. The Basic Operating and Scheduling System (BOSS) exhibits a particular philosophy of parallel processing organisation which is simple to understand and has proved convenient to use. The system provides a software model for a fully parallel microprocessor assembly for multi-channel on-line EEG analysis.
PROCESSES AND THE SCHEDULER
The fundamental unit is the ‘PROCESS’ which is realised as a contiguous area of core containing instructions, constants and workspace. A PROCESS is equated with a user ‘program’. When the 2050 computer is running a program (or process) and receives an interrupt all the central processor registers are automatically copied to a specified area of computer memory, which is arranged to be in the process header. After the interrupt level program has been executed the registers are automatically re‘instated and the background level processing continues. Thus to run a number of programs (or processes) quasi-simultaneously all that is needed is to arrange : (a) (b)
for interrupts to occur at regular intervals (we have chosen l/40 set) and that at each interrupt a different process is substituted so that each process gets a 25 msec time slot in turn.
The basic code is : cuproc : =[flink OF cuproc] ; Read as “The value in cuproc becomes the value in the memory cell/s indicated by the expression ‘Rink OF cuproc’“. Note
The main computer language in our unit is CORAL. In general, the implementation conforms to the official definition of ‘CORAL 66’ (HMSO) but relevant deviations are noted in the text.
In CORAL 66 this might be [3 +cuproc] ; the variable cuproc contains the address of the first byte of the current process,@k is an offset giving the relative position of theflink component if the process header is considered as a record. The construction could be achieved by using the macrogeneration facility but we have chosen to build the mechanism into the compiler because the ‘OF’ operator allows optimal code to be generated easily while an offset such as jlink can be auto-
A REAL-TIME PROGRAMMING SYSTEM
0 /
/0
\r
T
0
CV'RX
1 0
0
1 0
131
J v
J
0
0 Fig. 1. Processes are connected in a ring by FLINK pointers. The action of the scheduler can be visualised as a clock with the CUPROC pointer advanced one step at each ‘tick’.
matically set by a special ‘MAE’ communicator : MAE (INTEGER flink; ,BYTE type, priority, state, flags; INTEGER plink, owner, qlink; BYTE nl, n2, n3, n4, n5, n6, n7, n8 ; COMMENT these 8 bytes contain the name of the process as up to 8 ASCl 1 characters, without parity. The last character of the name has bit8 set to “1’. Unused bytes are undefined ; INTEGER creg, sreg, x3reg, x2reg, xlreg, amreg, alreg; BYTE status, wayno ; (this is the register dump area) INTEGER finptr, startptr, workptr, errptr); The above map defines alIthe components of the process header. Note that our implementation allows the use ,of byte variables as well as integer variables. The GEC 2050 is byte addressed but has a hardware register which when appropriately set allows machine-code instructions to operate on byte pairs which are equivalent to 16 bit integers. The MAE not only defines the offset but also indicates to the compiler the proper setting of the ‘L’ register. The integersJlink and plink concern us as present. They are used to hold the address of the first byte of another process and so are called pointers. Thejhk pointers are used to connect all the processes into a ring structure (Fig. 1). The scheduler can be imagined as a clock with the cuproc pointer one step clockwise at each tick. The code obeyed at each interrupt is as follows : timer : tick :=tick-1; IF tick < = 0 THEN
132
H. R. A. TOWNSEND
BEGIN tick : =40 ; (40 ticks/set) systime : = systime + 1; (systime counts seconds) END ; IF [plink OF cuproc] < > 0 THEN GOT0 run ; (priority processes do not time out) nxt : IF [plink OF cuproc] =O THEN cuproc : =[flink OF cuproc] ELSE BEGIN INTEGER nxp ; nxp : =[plink OF cuproc] ; [plink OF cuproc] : = 0 ; cuproc : = nxp ; END; IF [state OF cuproc] =0 THEN GOT0 run ELSE GOT0 nxt ; This also illustrates the priority mechanism. The plink is used to create an extra chain which takes priority over the normal ‘round-robin’ scheduler (Fig. 2).
@-A@-@ t
CUPROC
Fig. 2.
@
J
(a) Priority processes form a separate chain which takes priority over the normal ‘round-robin’ scheduler. (b) This priority chain is formed by the PLINK pomters (shown as++).
A REAL-TIME
PERIPHERAL
PROGRAMMING
133
SYSTEM
DEVICE INTERRUPTS
If an interrupt due to a peripheral device is detected then [wayno OF cuproc] is set by the hardware to contain the ‘way number’ of the interrupting device. This way number is used to discover the process which initiated the action of the peripheral, this process is started immediately or inserted in the priority chain as appropriate. The priority of the process is related to the peripheral which requires service, and is picked up at the same time (Fig. 3). device : way : =[wayno OF cuproc] ; devproc : =pproc$way] ; IF devproc =0 THEN GOT0 run ; (ie no process is available, ignore interrupt) IF [state OF devproc] < 0 THEN GOT0 run ; (a negative state implies a process which cannot run)
(4
TABLE OF PERIPHERAL PROCESSES
I
\
o-o
J
Fig. 3.. (a) WAY is used to discover the process to be run and the proper priority. In this case WAY 3 has prtority 2. (b) The selected process is inserted into the priority chain at a position determined by its priority.
134
H. R. A. TOWNSEND
[state OF devproc] : =O; dprior : = ppriofiway] ; [priority OF devproc] : =dprior ; IF [plink OF cuproc] =0 OR [priority OF cuproc] c dprior THEN BEGIN [plink OF devproc] : = cuproc ; cuproc : = devproc ; GOT0 run ; (devproc replaces cuproc and runs at once) END ELSE BEGIN INTEGER p, pl , p2 ; pl :=cuproc; p2 : =[plink OF cuproc] ; 10: p : =[plink OF p2] ; IF p < > 0 AND [priority OF p3] > = dpr-ior THEN BEGIN pl :=p2; p2 :=p; GOT0 10; (moves down the priority chain) END; [plink OF pl] : = devproc ; [plink OF devproc] : = p2 ; (inserts the device process into the priority queue) GOT0 run; END ;
COOPERATING PROCESSES
The key to the BOSS philosophy is the dynamic organisation of processes into cooperating systems. A system of cooperating processes is structured as a tree (Fig. 4). Each process has a pointer called OWNER and these pointers are used to define the tree, thus each process in a system-except one, the ‘root’ process-has one and only one ‘owner’ but may itself ‘own’ any number of subordinate processes. Inter-process communication is limited to these ‘owner’ links (i) The operating system supplies a handshake synchronisation mechanism (GET, PUT). (ii) A process may access the proper memory area of a subordinate. Otherwise no access is allowed outside the area of the process itself. In the current version of BOSS, this is not enforced by the operating system
AREAL-TIME PROGRAMMINGSYSTEM
135
Fig. 4. A system of cooperating processes is structured as a tree by using the OWNER pointers. A process may only access (a) its own proper core area and (b) the proper core area of its subordinates. The tree may grow or be pruned dynamically.
because to do so would unacceptably degrade the performance of the computer. With different hardware, however, illegal store accesses could easily be trapped.
BUILDINGIJPTHETRBE--CLAIM
Clearly when the system is started there must be at least one ‘root’ process. A running process may at any time ‘claim’ another process from the system. From the user point of view this is done by a statement : CLAIM (‘SUBORDINATE’,
sub) ;
This kind of procedure call causes a ‘program interrupt’. Running of the process is suspended automatically and the necessary manipulations carried out at interrupt level in a manner similar to that in which peripheral interrupts are served. The first parameter of the special procedure CLAIM is a string which gives the ‘name’ of the desired process. The second parameter is an integer to which a special ‘token’ is assigned by the action of CLAIM. This token is a pointer which may be used to access the subordinate process using a MAP by constructions like [xx OF sub] for reading or writing to the core of the subordinate. The token may also be used as a parameter of the special procedures GET(sub); PUT(sub); and with DISCARD(sub); DETACH(sub); see below.
Special procedures are provided to synchronise the activity of owner/subsidiary processes. Like CLAIM they act by causing a ‘program interrupt’.
136
H. R. A. TOWNSEND
The basic sequence is as follows : (4 A subordinate process starts running and, perhaps after some initialisation steps, executes GETOWN; at this stage running of the process is held up until the owner has executed PUT-unless of course this has happened already when there is no need for delay. (b) The owner, after a successful CLAIM, will usually set up some data in the subordinate’s store to define the task and then execute PUT(sub). When the subordinate has finished its task it executes PUTOWN; and (c) may then either return to step (a) or simply go into a waiting state in which it is ignored by the scheduler (this is the default action if the process reaches the end of its code-see ‘Example of two processes’ below). (4 The owner may carry out other computations after step (b) above but must sooner or later execute GET(sub); If the subordinate has not finished at this time then the Owner will be held up. After successful execution of this step the owner is free to examine the memory area of the subordinate to pick up the results, and the cycle may resume at step (a). The use of this particular synchronisation mechanism is not mandatory-for example it may be more convenient to use semaphores in the common variable area of the subordinate when the subordinate is maintaining a ‘circular buffer’ to be accessed by the owner-but it is generally convenient and has the advantage that a compiler can be devised to check from the structure of the program that the protocol has been properly observed. (Hill and Townsend, 1975). It is sometimes undesirable for the owner to be held up in step (d) above and therefore a special integer procedure PEEK(sub) is supplied which returns the ‘status’ of the subordinate-busy, ready, error. This allows an owner process to monitor several subordinates without knowing how long any particular one will take to run.
THECLAIM
PROCESS
The CLAIM mechanism itself is quite complex and therefore has to be implemented as a process-timesharing with other normal processes-rather than as interrupt level code. The claim process is privileged. A user process indicates a ‘claim’ to the operatit does. not run-and attached to a ing system. The process is suspended-i.e., queue special to the process CLAIM (the pointer OWNER in CLAIM is used for this purpose). The CLAIM process has several functions : (a) To CLOSE any processes marked as CLOSING. If any member of a system of cooperating processes is “CLOSING” then all members are to be marked similarly.
A REAL-TIME PROGRAMMING SYSTEM
137
FOR p : =pself, [flink OF p] WHILE p < > pseif DO BEGIN COMMENT this loop examines the entire ring of processes ; INTEGER pl ; IF [state OF p] = fclosing THEN BEGIN pl : =[owner OF p] ; IF pl < > 0 THEN closeproc(p1) ; END ; FOR pl :=pself, [flink OF pl] WHILE pl< >pself DO BEGIN COMMENT inner loop of the same kind ; IF [owner OF pl]=p THEN closeproc(p1); END; END; (PROCESS closeproc marks the process, a pointer to which is given as parameter as ‘closing’. ie. [state OF ptr] : =fclosing ;)
The next step is to close any peripheral devices owned by the process FOR j : = 1 STEP 1 UNTIL ndevs Do BEGIN IF pdevprocs(j) = p THEN BEGIN closedev(j); pdevprocs(j) : = - 1; END; END ;
The process is now marked fully closed. [state OF p] : = fclosed ;
@I The next operation is to delete any closed processes from the top of the process. stack. This step is omitted if there is no possibility of loading new processes from backing store. Such static systems must have all necessary processes loaded when the system is set up. The CLAIM mechanism is still useful in order to allow a subsidiary process to be shared (at different times) by processes on different branches of the system tree, or by processes which are members of different quasi-parallel systems. In the present ‘dynamic’ system processes are stacked on top of one another in the memory of the computer with a dummy ‘process’ BOSSE on top and connected as shown (Fig. 5).
138
H. R. A. TOWNSEND
PBOSS
Fig. 5. Processes are ‘stacked’ in core with a dummy process BOSSEon top and connected by FLINK pointers as shown. To delete the topmost process : (a) the dummy BOSSE has to be copied down to the new top of the stack ; (b) the backwards pointer has to be altered.
To delete the topmost process (1) the dummy BOSSE has to be copied down to the new top of the stack and (2) the back pointer has to be shifted. 10: p2 : =[flink OF pboss] ; pl : =[flink OF p2] ; IF [type OF pl] MASK protect = 0 AND [state OF pl] =closed THEN BEGIN copybosse(p2, pl); [pboss] : =pl ; GOT0 10; END ; Finally if there is a process requesting a claim then it is taken off the queue and the request string is picked up as NAME. newproc : = findproc(name) ; COMMENT findproc attempts to match the given string against the name of each process in the store ; IF newproc =0 THEN newproc : = loadprocess(name) ; COMMENT if a backing store is available then the desired process is looked up in a dictionary and loaded into main memory if available (see text); IF newproc < > 0 AND [state OF newproc] = closed THEN startup(newproc) ELSE GOT0 reject ; (ie. process is not available)
(c)
COMMENT PROCEDURE startup sets up the header of the process so that it willstart running, particularly [state OF newproc] : =O;
A REAL-TIME PROGRAMMING SYSTEM
139
PBOSS
Fig. 6. To add a PROCESS or BUFFER: (a) Space is claimed on top of the stack and a new copy of BOSSE is made; (b) the back pointer is altered; (c) the contents of the new buffer are set up; (d) if a new process has been created then the header is altered to allow it to run.
If NAME=0 then instead of finding and initialising a process a‘Buffer’ is created. This is a kind of ‘dummy subordinate process’ which does not run but is useful when a large dynamically determined workspace is required (Fig. 6). COMMENT required ;
length is an INTEGER
giving the number of bytes of buffer
pnew : =[flink OF pboss] ; pbosse : = pnew + lnhdr +length ; (lnhdr is the number of bytes required for the process header) IF pbosse +lnbosse > maxstore THEN GOTO reject ; copybosse(pnew, pbosse) ; [flink OF pbosse] : =pnew ; [flink OF pboss] : = pbosse ; The same mechanism is invoked when a new process is loaded from backing store. A buffer of the right size is first obtained, the body of the buffer is initial&d with code and then the header is updated to start the new process running.
A FINISHED
PROCFS~-DISCARD/DETACH/DIE
When a subsidiary process has carried out its task it will normally be ‘discarded’ by its owner process. DISCARD (. . . . .) clears the OWNER pointer of the process to be discarded and sets the process state tofclosing. The process and any subsidiaries are closed and eventually deleted by the CLAIM process already described. DETACH (...... ) is similar but sets the process state to 0 (i.e., nm). A detached process becomes the root of an independent system. For example a multi-user system can be created by a supervisor process which claims a control process for
140
H.R.A.TOWSEND
each of several VDUs (USERl, USER2 etc), each USER process being detached as soon as it is created. When the user has finished the process must execute DIE; This special procedure causes the STATE of the process itself to be set asfclosing.
PERIPHERALS AND
INPUT/OUTPUT
The relationship between a process and a peripheral device is essentially the same as that between an owner and a subsidiary process:Peripherals are identified by WAY numbers-determined by the hardware. Procedure RESERVE (wayno); is equivalent to CLAIM. Procedure INPUT/ OUTPUT (wayno, buffer, length) initiates a transfer, in a manner somewhat similar to PUT. There is of course a difference in that the peripheral ‘process’ is allowed to access the core of its ‘owner’. Procedure WAIT (wayno, time) is analogous to GET. If the peripheral has not completed its transfer then the process is suspended. The parameter time is to provide for a ‘timeout’ in case the peripheral is unable to generate a reply. When the peripheral replies, or the set time expires, the process is restarted with a suitable priority as already described. An integer procedure STATUS (wayno); is provided to allow the user to interrogate the status of the peripheral device. Procedure RELEASE (wayno); is the analog of DISCARD-a peripheral cannot of course be ‘detached’.
If a Service Request cannot be fulfilled by BOSS (e.g., a CLAIM for a process which is not available, or a timeout following a command to a peripheral) then error action is taken. The default action is to put the process into an ‘error’ state, in which it does not run (the process is not closed immediately because closure propagates to involve all the processes in a connected system-see the CLAIM process (a) above). If the owner of a suspended process attempts to communicate with it via GET, PUT or DETACH then this is an error on the part of the owner. The PEEK procedure may be used to discover that a subordinate process is suspended due to an error and also returns an indication of the cause of the error. The suspended process may subsequently be DISCARDed. A special procedure SETERROR ((procedure)) is provided which alters the error action so that instead of suspending the process, control is passed to the procedure which was last given as the parameter of SETERROR. This procedure can be arranged to take recovery action where this is appropriate-note that exit
A REAL-TIME
PROGRAMMING
SYSTEM
141
from the recovery procedure causes the program to resume immediately after the system procedure which caused the error, or alternatively the recovery procedure may jump to a global label. Where recovery is not possible the special procedure may simply report the fault. The system procedure ERROR (see example) causes the error action, either default or special as above, to be immediately and is therefore a general purpose error mechanism for the programmer.
EXAMPLE OF TWO PROCESSES
This is a very simplified example which might be used as a test of the operating system functions. The subsidiary process is named-for fairly obvious reasons-‘MULT’. The name is given as a string following the special language symbol PROCESS. An optional ‘common’ communicator defines an area which may also be accessed by the owner. The program proper is contained in a CORAL segment. CORAL PROCESS ‘MULT’; COMMON(INTEGER x, y, z); (Common is used as the area of a subordinate process which may be accessed by the “owner”) SEGMENT main ; BEGIN GETOWN; z:=x*y; PUTOWN; END; FINISH The test process continually executes a loop in which it claims “MULT” initialises x and y, runs the “computation” x * y in parallel with the subordinate, checks that the result is correct, and finally discards the subordinate. CORAL PROCESS ‘TEST’ ; MAP(INTEGER x, y, z); (This process has no “common”. The “map” communicator matches the “common” communicator of the subordinate process) SEGMENT main ; BEGIN INTEGER sub, a ;
142
H. R. A. TOWNSEND
LABEL loop; (In this implementation labels must be declared before use) loop : CLAIM(‘MULT’, sub); [x OF sub] :=17; [y OF sub] : =9 ; PUT(sub) ; (The subordinate process now runs in “parallel” and the owner may continue computation) a:=17*9; GET(sub); (The process may be held up at this stage waiting for the subordinate) IF a < > [z OF sub] THEN ERROR); DISCARD(sub); GO-IO loop ; END ; FINISH
DISCUSSION
The BOSS system is unconventional in that it concentrates simply on providing procedures to control the interaction of concurrently operating processes, and that it allows the overall system to be configured dynamically. The overriding design constraint was to make the operating and scheduling code as compact and simple as possible, so that it could be used in ‘Intelligent Terminals’ as well as in larger disc-based ‘File Systems’ (The current version requires 1 K bytes). Extra facilities are provided as desired by means of special processes rather than by modifying the operating system itself. Another unusual feature is the way in which peripheral devices are handled. Conventionally input and output are achieved by calls of operating system procedures, but this requires editing and recompilation of a new system whenever a peripheral is added or its mode of operation is altered, which can be a nuisance when a computer is used specifically to control experiments. The simplicity and flexibility of BOSS is not achieved without some constraints on the design of user systems and the chief of these is that the hierarchical structure must be ridgidly observed, with communication between processes only over owner/subordinate links, in which the owner is able to access the core of the subordinate but not vice-versa. The limitations have not however proved unduly restrictive in practice and are amply justified by the resulting freedom from undesirable interactions, such as the ‘deadly embrace’. A further limitation arises from the way in which processes are loaded into the
A REAL-TIME PROGRAMMING SYSTEM
143
computer memory as a ‘stack’. This means that the space occupied by processes which have finished their job and ‘DIEd’ may be impossible to reclaim because of an active process on top. Of course if the hardware design of the computer permitted ready relocation of a running process then this difficulty would disappear. A very attractive extension of the BOSS concept is to use the principles to design an assembly of small computer systems (microprocessors) which could perform true parallel computations rather than simply running processes concurrently by time-sharing as in a conventional computer. Ten times as much computation may be achieved in any given time by ten processes working simultaneously and the low cost of microprocessors makes this an attractive way of dealing with the large amounts of data such as are represented by, for example, EEG signals. The organization of parallel computing is rightly considered a difficult area and techniques are still being worked out. BOSS however can be considered as a software model of a fully parallel system, and, as we have seen, provided the hierarchical structure constraints are accepted, provides a well understood and simple framework for a processing system which could operate very fast indeed in ‘real-time’.
ACKNOWLEDGEMENTS
This work is supported by the Medical Research Council and the Lothian Area Health Board. I am greatly indebted to my colleague Dr. A. G. Hill, and I would also like to thank Professor D. Michie for his advice and encouragement.
REFERENCE HILL, A. G. and TOWNSEND,H. R. A., Deadlock-free parallel processing. International ference on Artificial Intelligence, Tbilisi, Sept., 1975.
Joint Con-
PROGRAMMING
H. R. A.
SYSTEM
TOWNSEND
Regional Clinical Neurophysiology Service, Western General Hospital, Crewe Road, Edinburgh EH4 2XU (Great Britain)
(Received: 15 May, 1978)
SUMMARY
The paper describes a Basic Operating and Scheduling System (BOSS) designed for a small computer. User programs are organised as self-contained modular ‘processes’ and the way in which the scheduler divides the time of the computer equally between them, while arranging for any process which has to respond to an interrupt from a peripheral device to be given the necessary priority, is described in detail. Next the procedures provided by the operating system to organise communication between processes are described, and how they are used to construct dynamically self-modifying real-time systems. Finally, the general philosophy of BOSS and applications to a multi-processor assembly are discussed.
SOMMAIRE
On decrit dans cet article un Systeme de Base Optrateur et Rt-partiteur (sigle anglais BOSS) concu pour un petit calculateur. Les programmes sont organist% comme des ‘processus’ modulaires independants et l’on akrit en &tail la faGon dent le temps du calculateur est reparti de faGon &gale entre ceux-ci, la priorite restant neanmoins donnte a tout processus akvant mtervenir a la suite dune interruption provenant dun disposittfptriphkique. On decrit ensuite les procedes oflerts par le systeme pour organiser les relations entre les processus ainsi que la maniere dent ils sont utilises pour construire des systemes en temps reel se modtjant dynamiquement eux-mcmes. Pour$nir on discute de la philosophie generale de BOSS et de ses applications d un montage multi-processeur. 129
ht. J. Bio-Medical Computing (10) (1979) 129-143 @Elsevier/North-Holland
Scientific Publishers Ltd.
130
H. R. A. TOWNSEND
INTRODUCTION
This paper describes an operating system designed for a small computer (GEC 2050) which is used for routine analysis of EEG records. The Basic Operating and Scheduling System (BOSS) exhibits a particular philosophy of parallel processing organisation which is simple to understand and has proved convenient to use. The system provides a software model for a fully parallel microprocessor assembly for multi-channel on-line EEG analysis.
PROCESSES AND THE SCHEDULER
The fundamental unit is the ‘PROCESS’ which is realised as a contiguous area of core containing instructions, constants and workspace. A PROCESS is equated with a user ‘program’. When the 2050 computer is running a program (or process) and receives an interrupt all the central processor registers are automatically copied to a specified area of computer memory, which is arranged to be in the process header. After the interrupt level program has been executed the registers are automatically re‘instated and the background level processing continues. Thus to run a number of programs (or processes) quasi-simultaneously all that is needed is to arrange : (a) (b)
for interrupts to occur at regular intervals (we have chosen l/40 set) and that at each interrupt a different process is substituted so that each process gets a 25 msec time slot in turn.
The basic code is : cuproc : =[flink OF cuproc] ; Read as “The value in cuproc becomes the value in the memory cell/s indicated by the expression ‘Rink OF cuproc’“. Note
The main computer language in our unit is CORAL. In general, the implementation conforms to the official definition of ‘CORAL 66’ (HMSO) but relevant deviations are noted in the text.
In CORAL 66 this might be [3 +cuproc] ; the variable cuproc contains the address of the first byte of the current process,@k is an offset giving the relative position of theflink component if the process header is considered as a record. The construction could be achieved by using the macrogeneration facility but we have chosen to build the mechanism into the compiler because the ‘OF’ operator allows optimal code to be generated easily while an offset such as jlink can be auto-
A REAL-TIME PROGRAMMING SYSTEM
0 /
/0
\r
T
0
CV'RX
1 0
0
1 0
131
J v
J
0
0 Fig. 1. Processes are connected in a ring by FLINK pointers. The action of the scheduler can be visualised as a clock with the CUPROC pointer advanced one step at each ‘tick’.
matically set by a special ‘MAE’ communicator : MAE (INTEGER flink; ,BYTE type, priority, state, flags; INTEGER plink, owner, qlink; BYTE nl, n2, n3, n4, n5, n6, n7, n8 ; COMMENT these 8 bytes contain the name of the process as up to 8 ASCl 1 characters, without parity. The last character of the name has bit8 set to “1’. Unused bytes are undefined ; INTEGER creg, sreg, x3reg, x2reg, xlreg, amreg, alreg; BYTE status, wayno ; (this is the register dump area) INTEGER finptr, startptr, workptr, errptr); The above map defines alIthe components of the process header. Note that our implementation allows the use ,of byte variables as well as integer variables. The GEC 2050 is byte addressed but has a hardware register which when appropriately set allows machine-code instructions to operate on byte pairs which are equivalent to 16 bit integers. The MAE not only defines the offset but also indicates to the compiler the proper setting of the ‘L’ register. The integersJlink and plink concern us as present. They are used to hold the address of the first byte of another process and so are called pointers. Thejhk pointers are used to connect all the processes into a ring structure (Fig. 1). The scheduler can be imagined as a clock with the cuproc pointer one step clockwise at each tick. The code obeyed at each interrupt is as follows : timer : tick :=tick-1; IF tick < = 0 THEN
132
H. R. A. TOWNSEND
BEGIN tick : =40 ; (40 ticks/set) systime : = systime + 1; (systime counts seconds) END ; IF [plink OF cuproc] < > 0 THEN GOT0 run ; (priority processes do not time out) nxt : IF [plink OF cuproc] =O THEN cuproc : =[flink OF cuproc] ELSE BEGIN INTEGER nxp ; nxp : =[plink OF cuproc] ; [plink OF cuproc] : = 0 ; cuproc : = nxp ; END; IF [state OF cuproc] =0 THEN GOT0 run ELSE GOT0 nxt ; This also illustrates the priority mechanism. The plink is used to create an extra chain which takes priority over the normal ‘round-robin’ scheduler (Fig. 2).
@-A@-@ t
CUPROC
Fig. 2.
@
J
(a) Priority processes form a separate chain which takes priority over the normal ‘round-robin’ scheduler. (b) This priority chain is formed by the PLINK pomters (shown as++).
A REAL-TIME
PERIPHERAL
PROGRAMMING
133
SYSTEM
DEVICE INTERRUPTS
If an interrupt due to a peripheral device is detected then [wayno OF cuproc] is set by the hardware to contain the ‘way number’ of the interrupting device. This way number is used to discover the process which initiated the action of the peripheral, this process is started immediately or inserted in the priority chain as appropriate. The priority of the process is related to the peripheral which requires service, and is picked up at the same time (Fig. 3). device : way : =[wayno OF cuproc] ; devproc : =pproc$way] ; IF devproc =0 THEN GOT0 run ; (ie no process is available, ignore interrupt) IF [state OF devproc] < 0 THEN GOT0 run ; (a negative state implies a process which cannot run)
(4
TABLE OF PERIPHERAL PROCESSES
I
\
o-o
J
Fig. 3.. (a) WAY is used to discover the process to be run and the proper priority. In this case WAY 3 has prtority 2. (b) The selected process is inserted into the priority chain at a position determined by its priority.
134
H. R. A. TOWNSEND
[state OF devproc] : =O; dprior : = ppriofiway] ; [priority OF devproc] : =dprior ; IF [plink OF cuproc] =0 OR [priority OF cuproc] c dprior THEN BEGIN [plink OF devproc] : = cuproc ; cuproc : = devproc ; GOT0 run ; (devproc replaces cuproc and runs at once) END ELSE BEGIN INTEGER p, pl , p2 ; pl :=cuproc; p2 : =[plink OF cuproc] ; 10: p : =[plink OF p2] ; IF p < > 0 AND [priority OF p3] > = dpr-ior THEN BEGIN pl :=p2; p2 :=p; GOT0 10; (moves down the priority chain) END; [plink OF pl] : = devproc ; [plink OF devproc] : = p2 ; (inserts the device process into the priority queue) GOT0 run; END ;
COOPERATING PROCESSES
The key to the BOSS philosophy is the dynamic organisation of processes into cooperating systems. A system of cooperating processes is structured as a tree (Fig. 4). Each process has a pointer called OWNER and these pointers are used to define the tree, thus each process in a system-except one, the ‘root’ process-has one and only one ‘owner’ but may itself ‘own’ any number of subordinate processes. Inter-process communication is limited to these ‘owner’ links (i) The operating system supplies a handshake synchronisation mechanism (GET, PUT). (ii) A process may access the proper memory area of a subordinate. Otherwise no access is allowed outside the area of the process itself. In the current version of BOSS, this is not enforced by the operating system
AREAL-TIME PROGRAMMINGSYSTEM
135
Fig. 4. A system of cooperating processes is structured as a tree by using the OWNER pointers. A process may only access (a) its own proper core area and (b) the proper core area of its subordinates. The tree may grow or be pruned dynamically.
because to do so would unacceptably degrade the performance of the computer. With different hardware, however, illegal store accesses could easily be trapped.
BUILDINGIJPTHETRBE--CLAIM
Clearly when the system is started there must be at least one ‘root’ process. A running process may at any time ‘claim’ another process from the system. From the user point of view this is done by a statement : CLAIM (‘SUBORDINATE’,
sub) ;
This kind of procedure call causes a ‘program interrupt’. Running of the process is suspended automatically and the necessary manipulations carried out at interrupt level in a manner similar to that in which peripheral interrupts are served. The first parameter of the special procedure CLAIM is a string which gives the ‘name’ of the desired process. The second parameter is an integer to which a special ‘token’ is assigned by the action of CLAIM. This token is a pointer which may be used to access the subordinate process using a MAP by constructions like [xx OF sub] for reading or writing to the core of the subordinate. The token may also be used as a parameter of the special procedures GET(sub); PUT(sub); and with DISCARD(sub); DETACH(sub); see below.
Special procedures are provided to synchronise the activity of owner/subsidiary processes. Like CLAIM they act by causing a ‘program interrupt’.
136
H. R. A. TOWNSEND
The basic sequence is as follows : (4 A subordinate process starts running and, perhaps after some initialisation steps, executes GETOWN; at this stage running of the process is held up until the owner has executed PUT-unless of course this has happened already when there is no need for delay. (b) The owner, after a successful CLAIM, will usually set up some data in the subordinate’s store to define the task and then execute PUT(sub). When the subordinate has finished its task it executes PUTOWN; and (c) may then either return to step (a) or simply go into a waiting state in which it is ignored by the scheduler (this is the default action if the process reaches the end of its code-see ‘Example of two processes’ below). (4 The owner may carry out other computations after step (b) above but must sooner or later execute GET(sub); If the subordinate has not finished at this time then the Owner will be held up. After successful execution of this step the owner is free to examine the memory area of the subordinate to pick up the results, and the cycle may resume at step (a). The use of this particular synchronisation mechanism is not mandatory-for example it may be more convenient to use semaphores in the common variable area of the subordinate when the subordinate is maintaining a ‘circular buffer’ to be accessed by the owner-but it is generally convenient and has the advantage that a compiler can be devised to check from the structure of the program that the protocol has been properly observed. (Hill and Townsend, 1975). It is sometimes undesirable for the owner to be held up in step (d) above and therefore a special integer procedure PEEK(sub) is supplied which returns the ‘status’ of the subordinate-busy, ready, error. This allows an owner process to monitor several subordinates without knowing how long any particular one will take to run.
THECLAIM
PROCESS
The CLAIM mechanism itself is quite complex and therefore has to be implemented as a process-timesharing with other normal processes-rather than as interrupt level code. The claim process is privileged. A user process indicates a ‘claim’ to the operatit does. not run-and attached to a ing system. The process is suspended-i.e., queue special to the process CLAIM (the pointer OWNER in CLAIM is used for this purpose). The CLAIM process has several functions : (a) To CLOSE any processes marked as CLOSING. If any member of a system of cooperating processes is “CLOSING” then all members are to be marked similarly.
A REAL-TIME PROGRAMMING SYSTEM
137
FOR p : =pself, [flink OF p] WHILE p < > pseif DO BEGIN COMMENT this loop examines the entire ring of processes ; INTEGER pl ; IF [state OF p] = fclosing THEN BEGIN pl : =[owner OF p] ; IF pl < > 0 THEN closeproc(p1) ; END ; FOR pl :=pself, [flink OF pl] WHILE pl< >pself DO BEGIN COMMENT inner loop of the same kind ; IF [owner OF pl]=p THEN closeproc(p1); END; END; (PROCESS closeproc marks the process, a pointer to which is given as parameter as ‘closing’. ie. [state OF ptr] : =fclosing ;)
The next step is to close any peripheral devices owned by the process FOR j : = 1 STEP 1 UNTIL ndevs Do BEGIN IF pdevprocs(j) = p THEN BEGIN closedev(j); pdevprocs(j) : = - 1; END; END ;
The process is now marked fully closed. [state OF p] : = fclosed ;
@I The next operation is to delete any closed processes from the top of the process. stack. This step is omitted if there is no possibility of loading new processes from backing store. Such static systems must have all necessary processes loaded when the system is set up. The CLAIM mechanism is still useful in order to allow a subsidiary process to be shared (at different times) by processes on different branches of the system tree, or by processes which are members of different quasi-parallel systems. In the present ‘dynamic’ system processes are stacked on top of one another in the memory of the computer with a dummy ‘process’ BOSSE on top and connected as shown (Fig. 5).
138
H. R. A. TOWNSEND
PBOSS
Fig. 5. Processes are ‘stacked’ in core with a dummy process BOSSEon top and connected by FLINK pointers as shown. To delete the topmost process : (a) the dummy BOSSE has to be copied down to the new top of the stack ; (b) the backwards pointer has to be altered.
To delete the topmost process (1) the dummy BOSSE has to be copied down to the new top of the stack and (2) the back pointer has to be shifted. 10: p2 : =[flink OF pboss] ; pl : =[flink OF p2] ; IF [type OF pl] MASK protect = 0 AND [state OF pl] =closed THEN BEGIN copybosse(p2, pl); [pboss] : =pl ; GOT0 10; END ; Finally if there is a process requesting a claim then it is taken off the queue and the request string is picked up as NAME. newproc : = findproc(name) ; COMMENT findproc attempts to match the given string against the name of each process in the store ; IF newproc =0 THEN newproc : = loadprocess(name) ; COMMENT if a backing store is available then the desired process is looked up in a dictionary and loaded into main memory if available (see text); IF newproc < > 0 AND [state OF newproc] = closed THEN startup(newproc) ELSE GOT0 reject ; (ie. process is not available)
(c)
COMMENT PROCEDURE startup sets up the header of the process so that it willstart running, particularly [state OF newproc] : =O;
A REAL-TIME PROGRAMMING SYSTEM
139
PBOSS
Fig. 6. To add a PROCESS or BUFFER: (a) Space is claimed on top of the stack and a new copy of BOSSE is made; (b) the back pointer is altered; (c) the contents of the new buffer are set up; (d) if a new process has been created then the header is altered to allow it to run.
If NAME=0 then instead of finding and initialising a process a‘Buffer’ is created. This is a kind of ‘dummy subordinate process’ which does not run but is useful when a large dynamically determined workspace is required (Fig. 6). COMMENT required ;
length is an INTEGER
giving the number of bytes of buffer
pnew : =[flink OF pboss] ; pbosse : = pnew + lnhdr +length ; (lnhdr is the number of bytes required for the process header) IF pbosse +lnbosse > maxstore THEN GOTO reject ; copybosse(pnew, pbosse) ; [flink OF pbosse] : =pnew ; [flink OF pboss] : = pbosse ; The same mechanism is invoked when a new process is loaded from backing store. A buffer of the right size is first obtained, the body of the buffer is initial&d with code and then the header is updated to start the new process running.
A FINISHED
PROCFS~-DISCARD/DETACH/DIE
When a subsidiary process has carried out its task it will normally be ‘discarded’ by its owner process. DISCARD (. . . . .) clears the OWNER pointer of the process to be discarded and sets the process state tofclosing. The process and any subsidiaries are closed and eventually deleted by the CLAIM process already described. DETACH (...... ) is similar but sets the process state to 0 (i.e., nm). A detached process becomes the root of an independent system. For example a multi-user system can be created by a supervisor process which claims a control process for
140
H.R.A.TOWSEND
each of several VDUs (USERl, USER2 etc), each USER process being detached as soon as it is created. When the user has finished the process must execute DIE; This special procedure causes the STATE of the process itself to be set asfclosing.
PERIPHERALS AND
INPUT/OUTPUT
The relationship between a process and a peripheral device is essentially the same as that between an owner and a subsidiary process:Peripherals are identified by WAY numbers-determined by the hardware. Procedure RESERVE (wayno); is equivalent to CLAIM. Procedure INPUT/ OUTPUT (wayno, buffer, length) initiates a transfer, in a manner somewhat similar to PUT. There is of course a difference in that the peripheral ‘process’ is allowed to access the core of its ‘owner’. Procedure WAIT (wayno, time) is analogous to GET. If the peripheral has not completed its transfer then the process is suspended. The parameter time is to provide for a ‘timeout’ in case the peripheral is unable to generate a reply. When the peripheral replies, or the set time expires, the process is restarted with a suitable priority as already described. An integer procedure STATUS (wayno); is provided to allow the user to interrogate the status of the peripheral device. Procedure RELEASE (wayno); is the analog of DISCARD-a peripheral cannot of course be ‘detached’.
If a Service Request cannot be fulfilled by BOSS (e.g., a CLAIM for a process which is not available, or a timeout following a command to a peripheral) then error action is taken. The default action is to put the process into an ‘error’ state, in which it does not run (the process is not closed immediately because closure propagates to involve all the processes in a connected system-see the CLAIM process (a) above). If the owner of a suspended process attempts to communicate with it via GET, PUT or DETACH then this is an error on the part of the owner. The PEEK procedure may be used to discover that a subordinate process is suspended due to an error and also returns an indication of the cause of the error. The suspended process may subsequently be DISCARDed. A special procedure SETERROR ((procedure)) is provided which alters the error action so that instead of suspending the process, control is passed to the procedure which was last given as the parameter of SETERROR. This procedure can be arranged to take recovery action where this is appropriate-note that exit
A REAL-TIME
PROGRAMMING
SYSTEM
141
from the recovery procedure causes the program to resume immediately after the system procedure which caused the error, or alternatively the recovery procedure may jump to a global label. Where recovery is not possible the special procedure may simply report the fault. The system procedure ERROR (see example) causes the error action, either default or special as above, to be immediately and is therefore a general purpose error mechanism for the programmer.
EXAMPLE OF TWO PROCESSES
This is a very simplified example which might be used as a test of the operating system functions. The subsidiary process is named-for fairly obvious reasons-‘MULT’. The name is given as a string following the special language symbol PROCESS. An optional ‘common’ communicator defines an area which may also be accessed by the owner. The program proper is contained in a CORAL segment. CORAL PROCESS ‘MULT’; COMMON(INTEGER x, y, z); (Common is used as the area of a subordinate process which may be accessed by the “owner”) SEGMENT main ; BEGIN GETOWN; z:=x*y; PUTOWN; END; FINISH The test process continually executes a loop in which it claims “MULT” initialises x and y, runs the “computation” x * y in parallel with the subordinate, checks that the result is correct, and finally discards the subordinate. CORAL PROCESS ‘TEST’ ; MAP(INTEGER x, y, z); (This process has no “common”. The “map” communicator matches the “common” communicator of the subordinate process) SEGMENT main ; BEGIN INTEGER sub, a ;
142
H. R. A. TOWNSEND
LABEL loop; (In this implementation labels must be declared before use) loop : CLAIM(‘MULT’, sub); [x OF sub] :=17; [y OF sub] : =9 ; PUT(sub) ; (The subordinate process now runs in “parallel” and the owner may continue computation) a:=17*9; GET(sub); (The process may be held up at this stage waiting for the subordinate) IF a < > [z OF sub] THEN ERROR); DISCARD(sub); GO-IO loop ; END ; FINISH
DISCUSSION
The BOSS system is unconventional in that it concentrates simply on providing procedures to control the interaction of concurrently operating processes, and that it allows the overall system to be configured dynamically. The overriding design constraint was to make the operating and scheduling code as compact and simple as possible, so that it could be used in ‘Intelligent Terminals’ as well as in larger disc-based ‘File Systems’ (The current version requires 1 K bytes). Extra facilities are provided as desired by means of special processes rather than by modifying the operating system itself. Another unusual feature is the way in which peripheral devices are handled. Conventionally input and output are achieved by calls of operating system procedures, but this requires editing and recompilation of a new system whenever a peripheral is added or its mode of operation is altered, which can be a nuisance when a computer is used specifically to control experiments. The simplicity and flexibility of BOSS is not achieved without some constraints on the design of user systems and the chief of these is that the hierarchical structure must be ridgidly observed, with communication between processes only over owner/subordinate links, in which the owner is able to access the core of the subordinate but not vice-versa. The limitations have not however proved unduly restrictive in practice and are amply justified by the resulting freedom from undesirable interactions, such as the ‘deadly embrace’. A further limitation arises from the way in which processes are loaded into the
A REAL-TIME PROGRAMMING SYSTEM
143
computer memory as a ‘stack’. This means that the space occupied by processes which have finished their job and ‘DIEd’ may be impossible to reclaim because of an active process on top. Of course if the hardware design of the computer permitted ready relocation of a running process then this difficulty would disappear. A very attractive extension of the BOSS concept is to use the principles to design an assembly of small computer systems (microprocessors) which could perform true parallel computations rather than simply running processes concurrently by time-sharing as in a conventional computer. Ten times as much computation may be achieved in any given time by ten processes working simultaneously and the low cost of microprocessors makes this an attractive way of dealing with the large amounts of data such as are represented by, for example, EEG signals. The organization of parallel computing is rightly considered a difficult area and techniques are still being worked out. BOSS however can be considered as a software model of a fully parallel system, and, as we have seen, provided the hierarchical structure constraints are accepted, provides a well understood and simple framework for a processing system which could operate very fast indeed in ‘real-time’.
ACKNOWLEDGEMENTS
This work is supported by the Medical Research Council and the Lothian Area Health Board. I am greatly indebted to my colleague Dr. A. G. Hill, and I would also like to thank Professor D. Michie for his advice and encouragement.
REFERENCE HILL, A. G. and TOWNSEND,H. R. A., Deadlock-free parallel processing. International ference on Artificial Intelligence, Tbilisi, Sept., 1975.
Joint Con-
