A Process Control Operating System with Interrupt Driven Scheduling

Copyright©JFAC Control Problerru and Devices Budapest, Hungary. 1980

A PROCESS CONTROL OPERATING SYSTEM WITH INTERRUPT DRIVEN SCHEDULING I. Bach, E. Farkas and L. Megyeri Computer and Automation Institute Hungarian Academy of Sciences, Budapest, Hungary

Abstract. In process control application due to concurrency and resource sharing quite a few tasks has to be performed by the operating systen. This is usually solved by special programs like schedular and by the implementation of well known software tools like semaphores, critical regions etc. In a given application for machine tool control special effort has been made to shift as many duties of the OS as possible to the sophisticated interrupt handling of the modern computer hardware. To achieve this goal that principle was kept in mind when partitioning the whole program that processes should not need new resources once already activated. This led to the fact that at all points of synchronization the process was terminated and a new process was founded. Besides each process was associated by a

~ossibly

distinct

interrupt level. Although due to hardware restrictions there principles could not be carried out perfectly the gain in speed and structure clarity is significant. rupt for synchronization not only of external

INTRODUCTION

but also of internal processes. Due to the In process control systems one of the most

facilities of the interrupt handling of the

difficult problems is the organization of the

modern hardware it turned out that a big part

cooperation, synchronization, commucation

of the scheduling task was performed by the

between both internal computational and ex-

hardware support automatically and both pro-

ternal peripherial (industrial) processes.

cessor assignement and process switching be-

One has to take into account both external

came much faster and easier.

(real time) and internal (resource sharing) conditions. To meet these requirements plenty of software tools like semaphores,

The

messa~e

desi~n

of the operating system was based

upon the idea that the partition of the whole

queues, monitor concept, critical regions

pro~ram

etc. has already been developped. As far as

activity oriented and processes should be

the synchronization with external processes

characterized

is concerned the interrupts have been always

system the processes are

playing big role.

package should be resource rather than by interrupt levels. So in our handlin~

the resour-

ces, and conmunicating with each other. Unfortunately

hardware constraints prevented

In an operating system devoted to machine tool

us to apply everywhere this phylosophy but

control special effort has been made to ex-

even so the gain in speed and 1n clarity of

ploit

the structurE was obvious and wc are convinced

the advantageous features of the inter77

I. Bach, E. Farkas and L. Megyeri

78

that for a large class of operating systems

Every process is associated with a given in-

and hardwares these principles can be used

terrupt level. This means that a process when

effectively.

running is executed at the interrupt level associated with it. Of course when establishing

THE ARCHITECTURE OF THE SYSTEM

the correspondence between processes and interrupt levels special attention

It is nlcost

compulsory to divide the whole

must be paid

on their importance. Processes performing more

program into sub tasks or using the generally

urgent functions should be associated with

accepted term into processes. \1hen partitio-

higher interrupt levels ensuring the correct

ning that principle was kept in mind that

priority.

each process at the moment of its activation should possess all the resources it needs

The execution at the interrupt level concludes

during its whole lifetime. The term resource

to the situation that a process can be preemp-

referes here not only to physical reusable re-

ted only by higher priority and therefore more

sources like disc but also to consumable ones

urgent processes. No additional measure is

like messages or interrupt stimuli, too. That

needed to achieve this 20al it is merely the

means that a process once activated may run

consequence of the hardware architecture of

upto its termination without being synchroni-

the computer.

zed by other concurrent internal or external processes. At the same time the activation of

For synchronization special processes can be

other processes is allowed at any moment of

established.

the lifetime of a process. Applying this principle consistently with each process a different interrupt level should be

EJ 6 6 8

associated. Unfortunately the hardware constraints of the computer did not allow us to be so perfect. Its consequence is - as it will

SUPERVISOR ENQUEUE DEQUEUE IT ENABLE IT DISABLE

ne

8

be shown later - that some scheduling work is

~

still done by the software.

8 EJ B EJ EJEJ FIGURE 1

THE SCHEDULING 11ECHANISM For the time bein2 let us suppose that the whole system is built up according to the above described philosophy. This means that no process needs additional resource during execution and with each process a

Making the partition according to this principle a process may be characterized by the

distinc~

in-

terrupt level is associated. The problems concerned the exceptions will be treated later on.

resources it possesses rather than its activity, by the service rendered. This may be called resource oriented partition. This philosophy

was kept strictly during the whole

i~­

plementation only few exceptions were made due to hardware restrictions.

To each process i.e. to each interrupt level belongs a message queue. As soon a process intends to activate an other process it sends a ffiessage to the latter's message queue and provokes a prograomed software interrupt at the level associated with the process to be activated.

79

A Process Control Operation System Depending upon the priorities of the sender

of those few registers which participate in

rsp. receiver processes either the necessarily

the hardware context saving action. No other

physically running sender proceeds its execu-

part of the memory may be shared between pro-

tion and the interrupt may becoce effective

cesses.

only after the sender will be already terminated or the sender will be preempted by the receiver.

This is not a severe restriction, for the processes are not

reentran~

only reusable. Re-

entrancy is automatically excluded since the As for external sticuli i.e. hardware inter-

interrupt stimulus remains valid during the

rupts the stimulus itself and the status byte

whole lifetime of the process therefore the

furnish the necessary information for the

interrupt level can not be stimulated and

identification of the event. Looking at the

the process activated again before terminated.

status byte as a special location for the message queue and its content as a possibly

CONCURRENCY AND RESOURCE SHARING

empty message both external and internal stimuli may be referred through the same ter-

Concurrency and resource sharing motivate the

minology.

organization

of the operating system. Al-

though physically only those processes may When the process isn't activated the program

be running which have a processor assigned to

counter of each interrupt level points to a

them from the operating system's point of view

small program called GET. When activated the

the number of conceptually concurrently run-

GET looks at the message queue and if not

ning processes may be different.

empty passes both message and control to the process associated with the interrupt level

In usual operating systems a process may be in

in question. After the process is terminated

one of three disjoint states RUNNING, READY,

the control is given back to the GET prograo

BLOCKED. In non preemptive systems each pro-

of the corresponding level which in turn checks

cess goes through in a cyclic way the states

again the message queue. So due to a new

BLOCKED-READY-RUNNING. When in BLOCKED state

message the process may be reactivated again.

the process is waiting for certain condition

In case of empty message queue the GET acknow-

message or stimulus etc. \Jhen READY the pro-

ledges the interrupt stimulus and the level

cess has all the resources it needs but pro-

becomes dormant.

cessor and when RUNNING in addition a proces-

to become true for instance the receipt of a

sor in assigned to it. It is the operating Of course if the process is preempted the

system's duty to manage all these state tran-

program counter of that level remains where

sitions and make the necessary bookkeeping.

it is pointing to a certain location of the process. So after all higher level interrupts

In preemptive systems in addition to the for-

having been acknowledged the process will re-

cer state transitions a couple of

READY-R~ING

suce exactly at the point where it was preemp-

to and back state transitions is performed as

ted.

soon as a preemption takes place.

Since the process switching is performed by

For the present operating system one can

interrupt stimuli and interrupt acknowledge-

hardly construct an analogous model. There is

ments the process context saving and restoring

no such thing like process description block

is made by the relevant hardware interrupt

and process state bookkeeping and so on. If

mechanism. The context consists of the content

one wants to characterize this system through

I. Bach, E. Farkas and L. Megyeri

80

a nodel it will have only two states let us call them RUNNING and

DOIU~T

but care must

be taken on the fact that the analogy between

Even simpler in the transition from RUNNING to

DOIU~T

state. The process having done its

duty just dies out beconing dormant without

the three state of the usual model and the

getting any help from the operating system.

new ones is far fron being perfect.

To be precise it is the GET program who finally "kills" the relevant interrupt level.

From the resource oriented partititon it fol-

It should be mentioned that also here there

lows that a process having once been activated

is no bookkeeping which is inevitable in the

never needs any new resource never waits. So

case of a usual operating system.

a process may not be blocked. The only difference between the running and The transition from

DO~IT

to RUNNING happens

dormant processes is that in former case a

in two steps. First a message and a stimulus

corresponding interrupt level is living. To

are sent and later the GET program passes both

be honest the above statement is true only

information and control to the process. The

if one regards the GET program as a part of

whole action is performed without any book-

the process. It is only the hardware which is

keeping. From the operating system's point of

aware of the stimulated or dormant state of

view as far as an interrupt level is living

the different interrupt levels. And it is the

i.e. the interrupt stimulus has not yet been

built in hardware interrupt mechanism who ma-

acknowledged the level and therefore the pro-

kes both scheduling and processor switching.

cess is in RUNNING state. It means that not only one but many processes can be at the same

As far as resource sharing is concerned the

time in RUNNING state. There is absolutely no

only resources where conflicts may occur are

difference in the treatment of conceptually

the message queues. When manipulating on

and physically running processes although on-

message queues it could happen that due to an

ly a single process the one with the highest

external interrupt an other process is acti-

priority proceeds really in its activity.

vated which also intends to interfere with the very same queue. This may lead to a situation that the message queue will not be in proper condition. To avoid such improper use of message queues the ENQUEUE function which forms a part of the supervisor first disables the interrupts and afterwords enables it again. The same situation is with that part of the GET program which analyzes the queue calling the DEQUEUE supervisor function with in an disable-enable bracket. This solution is quite common for establishing critical regions

FIGURE 2

in a one processor environment.

A Process Control Operation System PRACTICAL LIMITATIONS

81

sociate those processes with the same level which may not run concurrently due to the lo-

As it has already been mentioned hardware

gical structure of the whole system. This was

restrictions prevented us to associate each

our principle when associating more then one

process with a different interrupt level. So

process to a given interrupt level.

there must be interrupt levels with more than one process belonging to it. This was not in-

Another point to be mentioned here is. the qu-

dicated only by the number of the levels but

estion of those processes which do need addi-

there are levels having more the one periphe-

tional resources during their lifetime. There

ral devices.

are peripherals which allow only one byte information exchange at once. When the informa-

The one to one correspondence between proces-

tion

ses and message queues is still kept even in

send one byte as many times as many bytes the

this case. That means that the GET program

information

consis~

of more than one byte one has to

consis~of.

has to investigate all the message queues belonging to the interrupt level. Furthermore

In these cases our principle was violated and

it must decide which of the possible proces-

a single process was created to perform the

ses should be started depending upon the queue

whole function. Such a process needs unfortu-

where the message has been found.

nately additional resources namely the acknowledgement of the receipt of the byte sent.

The strategy applied when checking the different queues may lead to a certain secondary

The GET program of that particular level has

priority among the processes belonging to the

to take over practically all the duties of a

same level. The two priorities are of course

real schedular. It has to save and restore

not equivalent since processes with the same

context and in addition to avoid reentrancy

primary but different secondary priorities

it has to mask the queue belonging to the

may not preempt each other.

blocked process. The masking and demasking the queue corresponds to the putting the process

Few words about the philosophy applied when

into the BLOCKED and the RUNNING state. The

making the correspondence between processes

READY state has still no equivalent even in

and interrupt levels. Peripheral equipments

this case.

are always communicating through a given interrupt level. This is a feature of the hard-

At the same time we allowed the activation of

ware environment. The process handling a phe-

an other process at the same level. If the

ripheral equipment i.e. owing the equipment

GET finds a message in a not masked queu i.e.

as a resource is always associated with the

belonging to a different process of the same

interrupt level of the communication. This

level it will start it. So within the level

seems to be a logical and natural solution

we perform multiprocramming of course at the

since their message - in form of a status

expense of establishing under the nickname

word - will be found by the GET program of

GET almost a complete schedular.

that level. The third and last problem to be treated here The processes possessing as a resource a mes-

is the question of synchronization. According

sage sent by an other software process may be

to the principles of the original model this

associated with any interrupt level. Processes

may be solved by special processes checking

of the same level can not run from hardware

the presence of usually two messages sent by

reason concurrently. So it is advisable to as-

two different processes. It will activate the

I. Bach, E. Farkas and L. Megyeri

82

progr~

third synchronized process only if both mes-

In our implementation among the GET

sages has already arrived. In opposite case

8 belong to type

the synchronization process will terminate

C. It means that in the majority of cases the

without activating the third process.

pure system could be preserved.

From practical point of view these synchroni-

The GET programs are very simple because

~2

to type Band 2 to type

zation processes can be built into the GET

through supervisor calls they use the facili-

program. It is now the GET programs duty to

ties of the supervisor. The system has a su-

fulfil the above mentioned functions and de-

pervisor which is a collection of commonly used

cide whether the process to be synchronized

basic functions like queue handling, interrupt

should be activated or not.

enable, disable, peripheral handling, interrupt status handling ect.

IHPLEMENTATION The whole system forms an experimental manu-

An operating

syste~

has been built according

to the above described principles for machi-

facturing system at the Technical University of Budapest.

ne tool control purposes. It consists of a Hungarian made R-10 computer and two turning-

The technological system should manufacture

lathes and will be supplemented by a drilling

elements according to their technological des-

machine and an industrial robot.

cription written on a special language by hand or translated from description written in a

The computer has a word organization contai-

high level language like EXAPT.

ning two 8 bits bytes and the configuration contains a 800 K disc, two a1fanumeric displays, a punched tape reader and a tape puncher. The machine tools are driven by turning

~ lathe

Machine Tool Controllers which in turn communicate with the computer through British

MTC

Standard Interface channels.

machIne tool controller

ro~

~// robot controUe-r

From the potentially available 32 interrupt levels

for hardware reasons only 12 could

Ic=rr- EJ

be used. The whole program was divided into

Display 2

26 distinct processes. The processes were lo-

disc

FGIlE 3

gically and not evenly distributed among the levels. To the most populated one belongs 4 processes while six levels have 1 process each. The GET programs may be characterized by their

The computer system's duites can be summarized

function rendered. Type A only checks queues

as follows.

- possibly more than one - and activates processes. Type B organizes multiprocessing

It must manage the dia10g with the dispatcher

within the level. Finally type C performs in

through the first display. He can fed via tape

addition synchronization duties, too.

reader technological descriptions into the computer. He can arrange programs for manufacturing.

A Process Control Operation System

83

It must manage the dialog with the worker

The system can manage only static priorities

through the tastature of the MTC. He can ope-

determined in implementation phase. Where for

rate the machine tool by hand via MTC-compu-

some reason for instance due to the tight re-

ter. He can set the machine tool and finally

al time requirements of the enviroment dyna-

he can start the program for manufacturing.

mic priorities are needed the method can not be applied.

The computer when manufacturing takes the technological description from its date base trans-

Even when priorities might be static one has

late in run time each sentence into instruc-

to face a lot of restrictions. The processes

tions for the }ITC and synchronized by the

communicating with hardware devices should be

machine tool itself sends the instructions to

associated with the level where the communi-

the MTC. The worker can of course interfere

cation takes place. When more than one process

at any time and take over the control.

has to be associated with one level the logical choice also denotes a constraint. Al-

The fulfillment of the real time requirements

together priorities can not be chosen arbitra-

of the industrial process is ensured by the

rily

adequate priorities of the urgent functions

restriction.

but this does not usually mean a serious

and by the relatively high speed of the computer. No additional measure has been made.

From the program structure point of view it is not very sympathetic that the GET programs

Due to the experimental nature of the system

whose task is usually and logically performed

its facilities should be extended in the futu-

by the supervisor belong to the user program.

re i.e. new processes must be introduced.

The multiplication of the GET programs i.e. the distribution of the scheduling does not

CONCLUSION

mean a big burden since the normal GET program consist of few instructions mainly supervisor

Exploiting the sophisticated interrupt hand-

calls.

ling facilities of the modern hardware one can build an effective operating system of clear

The biggest problem was what we described as

structure where scheduling, process switching

practical constraints. We have chosen a com-

and bookkeeping can be done by the hardware.

puter which was available. When using a com-

This solution decreases the overhead of sche-

puter with more flexible hardware the advan-

duling both in program and running time.

tages were even bigger. So when using these principles in the micros where everything de-

We think that the advantages are trivial and

pends upon our decision the advantages can be

they are fully described in the report.

exploited totally.

To mention few drawbacks first of all we have

Having stated all the disadvantages we had to

to call the attention of the fact that this

face or we could imagine we are still enthu-

method can be applied only for a certain class

siastic and we are going to apply this method

of software systems. The information flow must

in the future as many times as the enviromen-

be unique in the system so where a resource

tal conditions make it possible.

may be consumed by more than one process the principles may not be used because here it is the sender who determines the destination of the information and not the receiver.