Software Control Synchronization Primitives for Mass Service Like Real Time Systems

REAL-TIME LANGUAGES AND OPERATING SYSTEMS

SOFTWARE CONTROL SYNCHRONIZATION PRIMITIVES FOR MASS SERVICE LIKE REAL TIME SYSTEMS

J.

KraI,

J.

Demner and V. Kostecka

Institute for Computation Techniqu es of the

CVUT, Horskii 3,

Praha 2, Czechoslovakia

Abstract. In last years many high level language synchronization primitives (semaphoree,critical regions, messages, monitors etc.) were invented. The primitives are intended to be used in operating systems and/or in real time programming. The variety of tools reflects, it seems, not only the state of the art. It is likely that due to various reasons (hardware limitations, response time etc.) the decision what primitives are to be used (or invented) depends on the problem to be solved. If the response time need not be too short and a greater overhead of an supervisory program is admissible more sophisticated means can be used. Moreover some means can reflect the situation and the intuition in some area of applications better than others. In the paper synchronization constructs for discrete system control software are discussed. The constructs were used with success in practical applications. The constructs are based on a list of jobs to be performed together with the conditions which must be satisfied before the job is performed. In order to program the parallel and sequential tasks easily it is possible to call a process "in parallel" as well as like a subroutine. The tools described below are very powerful and flexible in use. Their properties were verified in a machine tool workshop control software. The constructs seem to be useful in many real time systems especially in production process control software. Keywords. Control software, synchronization primitives, real time programming, production control, programming control.

The workshop consists of (i) working places WI, W2, W3, ••• j (ii) computer controlled transport cars Cl, C2, C3 j (iii) the "reload" machines TI, T2, T3, T4 able to move a transport unit from the place serviced by the Cl, or C2 into a place serviced by

INTRODUCTION In order to formulate our design primitives we shall discuss the problem of the control software for the control of the transport means in a machine tool workshop given in Fig.l.

169

J.

170

Kr~1,

J. Demner and V. Kostecka

C3 (and vice versa). If a transport uni t p is to be moved from vI) to Wl (say) the following sequence of actions must be performed. T3 to line of C2j C2 to W3, loadj C2 to T3, unload; move T3 to C3; move T3 to C3j C3 to T3, load; C3 to Tl, unload; etc. The requirements of transport actions are generated in the moment when a workplace Wi ends its technological operation (or in the moment that Wi is not supplied by the materials for next y hours). Due to various reasons during the actions of transport means many errors can occur (wrong number of a transport unit,load from an empty place, action is not finished in time, etc.). The errors must be elaborated and recovered. The response time is 1 to 3 seconds. If the transports from Wl to W3, W3 to Wl, W3 to W2, W5 to W2 are to be performed the reload machines T3, T2, T3, T4 can be loaded simultaneously and the phenomenon called in operating systems deadlock can occur. The deadlock must be prevented. Cl

C2

Wl W2

W3 W4 W5

We can now formulate the following design for the synchronization primitives: (i) The actions can be performed in parallel as well as sequentially (ii) The conditions for an action can be quite complex (in our example a transport action can be started only if it causes no deadlock). (iii) An action should produce a message containing the information on its result. BASIC SYNCHRONIZATION CONSTRUCTS We shall now attempt to meet the above design objectives. An action in the above sense will be represented by an algorithm (or by a subroutine)A. The A can have parameters Pl, ••• ,Pn and it can return a result r.We shall (like in Algol 68 or PASCAL, Van Wijngaarden (1975), Wirth, Jensen (1974» have the possibility to define the types of parameters and the type of result in the form (for k=O the brackets are omitted) process A

the process body; The process can be "called", or in two statements ~ A(Pl,···,Pk) as soon as

T]) C3

====

computer controlled transport line Ti machine connecting two transport lines (it can contain a transport unit) Cl,C3,C2 transport cars Wi machines (working places) Fig. 1

= alg(~lxl, ••• ,~~)mres used

(1)

c(ql'··· ,qs) ~ and ~

A(pl' ••• ,I\:) as soon as

(2 )

c(ql'··· ,qs) end In (1) and (2) the condition c is a boolean procedure returning ~ or~. The process A in (1), (2) will be called the object, the process/program containing (1) and/or (2) is the SUbject. (2) generates the requirement to perform A(Pl, ••• ,I\:) as soon as the condition c( ••• ) is true. (2) causes no delay in the per-

Software contro l synchronization primitives

forming of the actions of the subject. The ~ statement has a value - the name of the process implicitly generated by the ~ statement. The £!!! statement (1) works like start statement, but the subject waits in it till (i) c( ••• ) is true; (ii) A is performed. The resulting value of A (e.g. the error code) is then value of the ~ statement. Example 1. A part of the program of the control software for the workshop from Fig.l. comment generate new actions comment 1££ i 12 number of workingplaces ~ g a2! materia1(i) ~ !U!tl transport (addr of unit for (i), adr of W(i)} as soon as nodeadlock ~; In "transport" the first command is performed and evaluated as follows. begin ~ ~ turnT(i,right} as soon as Tempty (i) ~ £ first command performed, evaluate its result £ la OK: skip error: return (error 1) £ terminates transport £ ~

........

The implementation of above constructs allows an easy implementation of ~ (B( ••• » causing the delay of the subject till B is true. Using !!!!(B} the semaphore operations can be implemented by !!!1(sem};sem:=false and sema:=true respectively provided that the first two operations are performed as one individable operation. This is satisfied if (from the point of view of a programmer) the process actions are performed in an individable manner till wait or end or call statement is reached (this~es n~xClude invisible interrupts on hardware level returning the control to the interrupted plaoe) •

171

MESSAGE BUFFERS

The above synchronization constructs are very powerful but they are not flexible enough in some situations. (i) It is not too easy for a process to synchronize its actions with some other (parallel) process. (ii) Our synchronization primitives require that the whole system must be designed in a centralized way; moreover we must have some means of communication with standard operating system (say), with same other systems with different properties (e.g. drivers of peripherals, programs with dynamic objects like arrays, recursive procedures) possibly written by different teams of programmers and working in a different memory segments etc. (iii) It is very important to have the possibility to decrease the response time and the system overhead. We introduce a new tool similar to that given in Hansen (1972). The synchronization is based on the principle of sending a message / wait for a message. The messages are send via messages buffers. The message is a data structure (record in PASCAL). A message buffer b is an abstract data structure which can contain at most "capacity of b" messages of a prescribed type. The message buffer is introduced by the declaration mbuffer capacity (3) The declaration (3) introduces message buffer which can contain at most <'number> messages. A messs.ge buffer is filled by the ~ statement. It causes the subject

to be blocked (if ~ is applied on a full buffer) till the buffer is not full. There is the possibility wait for answer 1n the ~ statement,

J. Kral, J. Demner and V. Kostecka

172

to determine the message destination and to test by the operation ~ whether the answer came in time. A message is taken from the buffer by statement ~ (message buffer) ~ fi:Q.m q\ ~ in t} waiting for message from q (if prescribed) t time units (if prescribed) provided that message has the destination not different from the subject. Now we can write a program for printer

i!

E ~ ~ printer ( •.. ) activate print ~ answer print .!:ill 3 sec ~ !b!n terminate (print, error) else elaborate (E) fi terminate terminates the process and prescribes that it returns the value error.

*"

CONCLUSIONS A set of synchronization primitives was presented. The primitives were used in practice on assembler level and they proved themselves to be very powerful, flexible and easily implementable. The disadvantages (long response time, a great system overhead) were not substantial. The primitives allowed to cooperate easily with standart operating system (K-ORG of the Siemens 330 computer). The use of message buffers allows as well a simple separation of the software subsystems implemented by different teams. The discussed constructs were to some degree inspired by some software products (Siemens, Hewlett Packard etc.) as well as by the research published in last years (Wirth (1971), Hoare (1918), Brinch-Hansen (1918), Kessels (1971». It is intended to verifY our constructs in further applications and then use them in the frame of a high level language.

REFERENCES Brinch-Hansen, P. (1972). Structured Multiprogramming. Comm. A.C.M. li)

1. Brinch-Hansen, P. (1918). Distributed Processes: A Concurrent Programming Concept. Comm. A.C .M.ll. p. 934. Demner, J. (1911). Primitive constructions for real-time software. ~ polytechnica .§. (IV, 2, 1911). Dijkstra, E.W. (1968). The Multiprogramming System. Comm. A.C.M. Hoare, C.A.R. (1914). Monitors, an Operation Systems Structuring Concept. Comm. A.C.M., 11, No.lO, 549-551. Hoare, C.A.R. (1918). Communicating sequential processes. Comm. A.C.M. ll, No 8, 662-611. Kessels, J.L.W. (1911). An Alternative to Synchronizations in Monitors, Comm. A.C.M., 20,1, 500-503. Kral, J., Demner, J. (1911). Towards reliable real time programming. Proceedings of the Conference on Construction of Quality Software, North Holland. Kral, J., Demner, J. (1918). New synchronization primitives for realtime programming. Acta Polytechnica 1. , (IV, 1, 1918), p.41. van Wijngaarden (1915). Revised Report on the Algol 68 Language. Acta Informatica ~, No.1-3. Wirth N., Jensen, K. (1914). PASCAL User Manual and Report. Lecture Notes in Computer Science ~. Springer V., Berlin, 110 pp.