SUID-AFRIKAANSE REKENMRSIMPOSIUM

SOUTH AFRICAN COMPUTER SYMPOSIUM

HOUQAY INN PRETORl{I

JULIE 1 - 3 JULY 1987

Proceedings of the

4th South African Computer Symposium

Bolldq Inn, Pretoria

1 - I July 1987

edited by

Pieter Krit1inger

Computer Science Department University of Cape Town

PREFACE

Computer science is an emerging discipline which is having difficulty in being recognised as a worthy member of the sciences. I will paraphrase John Hopcroft, co­winner of the 1986 Turing Award, when, during a recent interview, he said that the primary reason for the lack of recognition, is the · age of our' researchers. Probably not one of the researchers who presented their work at this symposium is older than 45. I know of no computer scientist in South Africa who is in a position where (s)he can affect funding priorities. As far as I know we have no representation on any of the commit'tees of the Foundation for Research Development and for our Afrikaans speaking fraternity, none who is a member of the A.bdemie vir Wetenslrap en Kuns. n will take time and conscious effort to establish our presence. The same is true of course for our universities. Again, with one exception, I know of no dean of a science faculty, vice-principal or principal who is a computer scientist. We consequently spend an enormous amount of time trying to explain the needs of computer science and its difficulties. I believe this symposium is a further step towards accreditation by our peers and superiors from the other sciences.

The total number of papers submitted. to the Programme Committee for con­sideration was 34. Each paper was reviewed by three persons knowledgeable in the field it represents. Of those submitted., "23 were finally selected for inclusion in the symposium. As a result the overall quality of the papers is high and as a computer science community in Africa we can be justly proud of the final programme.

This is the fourth in the series of South African computer symposia. This year the symposium is sponsored by the Computer Society of South Africa (CSSA), the South African Institute for Computer Scientists and the local IFIP Committee. The executive director of the CSSA and his staff deserve warm thanks for handling the organisation as well as they have, while the Organising Committee provided Derrick and I with very valuable advice.

Finally I would like to express my sincere appreciation to the authors, to the members of the Programme Committee and particularly the reviewers. Without the kind cooperation of everyone, this symposium would not have taken place.

Pieter IfritziD.ger July 1981.

1.

SYMPOSIUM CHAIRMAN: PS Kritzinger, University of Cape Town.

SYMPOSIUM CO-CHAIRMAN: D Kourie, University of Pretoria.

MEMBERS OF THE PROGRAMME COMMITTEE

Judy Bishop, Witwatersrand University

Chris Bornman, UNISA

Hannes de Beer, Potchefstroom University

Gideon de Kock, Port Elizabeth University

Jaap Kies, Western Cape University

Derrick Kourie, Pretoria University

Pieter Kritzinger, Cape Town University

Tony Krzesinski, Stellenbosch University

Michael Laidlaw, Durban Westville University

Peter Lay, Cape Town University

Ken MacGregor, Cape Town University

Theo McDonald, Orange Free State University

Jan Oosthuizen, University of the North

Dennis Riordan, Rhodes University

Alan Sartori-Angus, Natal University

John Shochot, Witwatersrand University

Theuns Smith, Rand Afrikaans University

Trevor Turton, ISM (Pty) Ltd

Gerrit Wiechers, Infoplan.

ii

LIST OF REVIEWERS

BERMAN Sonia

BISHOP Judy

BORNMAN Chris

CAREY Chris

CHERENACK Paul

DE BEER Hannes

DE VILLIERS Pieter

GORRINGE Pen

KIES Jaap

KOURIE Derrick

KRITZINGER Pieter

KRZESINSKI Tony

LAIDLAW Michael

LAY Peter

MacGREGOR �en

MATTISON Keith

McDONALD Theo

RENNHACKKAMP Martin

RIORDAN Denis

SATORI-ANGUS Alan

SCHOCHOT John �·· SMITH Theuns

TURTON Trevor

VAN DEN HEEVER Roelf

VAN ROOYEN Hester

VON SOLMS Basie

VOS Koos

,.

iii

TABLE OF CONTENTS

Keynote Address

"An Extensible System and Programming Tool for Workstation Computers.". . • • • . • • • • • • • • • • • . • • . . • . • • • • • • • • • • • 1 Niklaus Wirth, ETH, Zurich

Invited Lectures

"The Relationship of Natural and Artificial Intelligence." .•.•.••....••.••. not included in Proceedings. G Lasker, University of Windsor, Ontario. , "Software Engineering: What Can We Expect in the Future?" ••••••.••.••••••••• not included in Proceedings. D Teichrow, University of Michigan, U.S.A.

Computer Languages I

"SPS-Algo·l: Semantic Constructs for a Persistent Programming Language." • • • • • • • . • • • . . • • • • • • • • • • • • • • • • • • • . . 13 s Berman, University of cape Town.

"Petri Net Topologies for a Specification Language." ..•• 25 R Watson, University of the Witwatersrand.

"Towards a Programming Environment Standard in LISP." •.• 45 R Mori, University of Cape Town

"ADA for Multiprocessors: Some Problems and Solutions." •• 63 J Bishop, University of the Witwatersrand.

Computer Graphics

"Polygon Shading on Vector Type Devices." ••.••••••••••.• 75 CF Scheepers, CSIR.

''Hidden Surface Elimination in Raster Graphics Using Visigrams. '' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 P Gorringe, CSIR.

Database Systems I

"On Syntax and Semantics Related to Incomplete· Information Databases." . . . . . • . • • • • • • • • • . • . • • . . • . • • . • • • • 109 ME Or1owska, UNISA.

"Modelling Distributed Database Concurrency Control overheads. '' ............. · . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 131 M H Rennhackkamp, University of Stellenbosch.

Operating Systems

"The Development of a Fault Tolerant System for a Real-time Environment." . • . • • • • • . • • • • • . . . • • • . • • . . . • • • • • . 149 M Morris, CSIR.

"A New General-purpose Operating System." .•••••••••.••• ,161 B H Venter, CSIR.

iv

Computer Languages I I

"The Representation of Chemical Structures by Random Context Structure Granunars." • . . . . • . . . . • • • . . • . . . . . • • . . . • 17 5 EM Ehlers and B von Solms, RAU.

"A Generalised Expression Structure." .......••...•....• 189 w van Biljon, CSIR.

Computer Networks and Protocols I

"An Approximate Solution Method for Multiclass Queueing Networks with State Dependent Routing and Window Row Control." ................................... 203 A E Krzesinski, University of Stellenbosch.

"A Protocol Validation System." ••...........•...•.•.... 227 J Punt, University of Cape Town.

Computer Networks and Protocols II

"Protocol Performance Using Image Protocols." .....•.... 251 P S Kritzinger, University of Cape Town.

Artificial Intelligence

"A Data Structure for Exchanging Geographic Information.'' .......................................... 267 A Cooper, CS IR.

"The Design and Use of a Prolog Trace Generator for CSP." ................................................. 27 9 D G Kourie, University of Pretoria.

Database Systems I I

"An Approach to Direct End-user Usage of Multiple Databases." . ... • . . . . . . . • . . . . • . . . . • . . . . . • • . . . . • . . . • . . . . . . 297 M J Phillips, CS IR.

"A Semantic Data Model Approach to Logical Data Independence. '' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 9

S Berman, University of Cape Town.

Information Systems

"The ELSIM Language: an FSM-based Language for the ELSIM SEE.'' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . • • . . . . . . . . . • • . . 343 L du Plessis and C Bornman, UN ISA.

"Three Packaging Rules for Information System Design." . 363 J Mende, University of the Witwatersrand.

V

computer Languages I I I

" Experience with a Pattern-matching Code Generator." ... 371 M A Mulders, DA sewry and W R van Biljon, CS IR.

"Set-oriented Functional Style of Programming." c Mueller, University of the Witwatersrand.

Tutorial

385

The use of Modula-2 in Software Engineering." .....••... 399 N Wirth, ETH, Zurich.

vi

•

07h30

08h45

09h00

10h00

10h15

10h50

11h25

11h50

12h30

14h00

14h35

1 Shl S

15h30

16h05

18h00

Aegistration and Coffee.

Welcoming address, President of the South African Institute of Computer Scientists, Dr. G. Wiechers.

Invited Lecture. Professor D. Teichrow, University of Michigan. Software Engineering, ... What Con We Expect in the Future.

COFFEE

Computer languages I. Chairman: G. Wiechers.

S. Sermon, University of Cape Town. SP>Algol: Semantic Constructs for o Persistent Programming Language.

A. Watson, University of the Witwatersrand. Petri Net Topologies for o Specification Language.

A. Mori, University of Cape Town. Towards a Progrommiog Environment Standard in USP.

J. Bishop, University of the Witwatersrand. ADA for Multiprocessors: Some Problems and Solutions.

LUNCH

Computer Graphics. Chairman: D. Kot.Jrie

C. F. Scheepers, �IA. Polygon Shading on Vector Type Devices.

P. Gorringe, CSIA. Hidden Surface Elimination in Roster Graphics Using Visigroms.

COFFEE

Database Systems I. Chairman: 8. von Solms.

ME. Orlowska, UNISA.

On Syntax and Semantics Related to Incomplete Information Databases.

MH. Aennhackkamp, Stellenbosch University. Modelling Distributed Database Concu"ency Control Overheads

Operating Systems. Chairman: K. MacGregor.

fl\. Morris, UNISA. The Development of o Fault Tolerant St,1stem for o Reof-time Environment

8. H. Ve:nter, CSIA. A New General-purpose Operating Svstem.

COFFEE

Computer languages II. Chairmon;..J;- Bishop.

E.M. Ehlers and 8. von Solms, Randse Afrikaanse Universiteit. The Representation of Chemical Structures by Random Context Structure Grammars.

W. van Biljon, CSIA.

A Generalised Expression Structure.

Cocktail Party in Cullinan Room A.

vii

ll)A\"' 11

I-

08h30

09h30

10h05

10h30

11h00

11h35

12h30

14h00

14h35

15h15

15h30

16h05

16h45

19h30

Keynote Address by Profesor Niklaus Wirth, Swiss Federal Institute for Technology, Zurich. An Extensible Svstem and a Programming Tool for Worhstotion Computers. Computer Networks and Protocols I. Chairman: P.S. Kritzinger.

A.E. Krzesinski, University of Stellenbosch. An Approximate Solution Method for Multicloss Queueing Networks with State Dependent Routing and Window Row Control. J. Punt, Universitt; of Cope Town. A Protocol Validation Svstem. COFFEE

Computer Networks and Protocols II. Chairman: A. van der Heever.

P.S. Kritzinger, Universil:\J of Cape Town. Protocol Performance using Image Protocols. Invited Lecture by Professor G. lasker, University of Windsor, Ontario. The Relationship of Natural and Artificiol Intelligence. LUNCH

Artificial Intelligence. Chairman: G. Lasker.

Database Systems II. Chairman: C. Bornman.

MJ. Philips, CSIA. An Approach to Direct End-user Usage of Mutiple Databases. S. Berman, University of Cape Town.

A Semantic Doto Model Approach to Logical Doto Independence.

Information Systems. Chairman: D. Teichrow.

L du Plessis and C. Bornman, UNISA. The ElSIM Language: on FSM-bosed Language for the ElSIM SEE

J. Mende, University of the Witwatersrand.

Three Packaging Rules for Information Svstem Design. COFFEE

Computer languages Ill. Chairman: N. Wirth.

W. van Biljon, CSIA. Experience with a Pattern­matching Code Generator. C. Mueller, University of the Witwatersrand. Set-oriented Functional Sf:',Jle of Programming.

Open Forum with professors G. Lasker, D. Teichrow and N. Wirth. Moderator: Dr. D. Jacobson.

Symposium Banquet in Cullinan Room. Guest speaker, Dr. D. Jacobson,. Group Executive: Technology, Allied Technologies Limited.

viii

A. Cooper, CSIA R Doto Structure for Exchanging Geographic Information.

08h00

08h30

12h15

12h30

Registration (Tutorial.only).

Tutorial. The Tutorial will be given by professor Niklaus Wirth, Division of Computer Science, Swiss Federal Institute of Technology, Zurich.

The use of Modu/a-2 in Software Engineering. Topics to be covererd include:

What is Software Engineering? Data types and structures. Modularization and information hiding. Definition and implementation parts. Separate compilation with type checking.

· Facilities to express concurrency. Pompous programming style. What could be excluded?

Close of Symposiurri.

LUNCH

be ·

A NEW GENERAL-PURPOSE OPERATING SYSTEM

by

B . H . Venter

Computer Science Div ision , NRIMS , CSIR, Box 395 , Preto r ia

ABSTRACT

The cur r ent gener ation of widely-used , mul ti-user , gene r al-purpose operat ing systems have evol ved f rom versions that were designed when many of the i s s ue s that a r e impo r tant today were unimpo r tant o r no t even thought of . Th i s evol ution has not been tot�l ly successful . In par ti cul ar , the cur r ent generation is i l l sui ted fo r impl ementation o n loosely-co upled mul t i-processo r s .

A new operating sy stem, designed w i th cur r ent r eq ui rement s in m ind , and flexibl e eno ugh to adapt successf ul ly to l ikely futur e r eq ui rements , has been devel oped a s pa r t of a proj ect to build a l oosely-co upl ed mul ti-processo r system that shoul d have the pe rformance and f unct ional i ty of a ' s uper main- f r ame ' computer .

Thi s pape r concentr ates on de s cr ibing the fundamental mechanisms of the ope rating sy stem : processe s , inter-process communica tion, and serve r s . · rt al so br iefly outl ines the suppo r t prov ided fo r data secur i ty , database appl ications , and r eal- t ime appl ications .

KEYWORDS AND PH'RASES :

ope r ating sy stems , system cal l s , inter-process communication , di str ibuted sy stems , operating sy stem secur i ty , ope rating system database s uppo r t , real- time .

1 . INTRODUCTION AND ·MOTIVATION

A mode r n gene r al -purpo se ope rating sys tem can be expected to prov ide a high l evel of da ta secur i ty , to pr ov ide appropr i ate suppo r t for a compr ehensive databa se management system , and to s uppo r t r eal- t ime appl ica tions . Fur thermor e , s uch a sy stem can be e xpected to i sol ate appl i ca ti ons f rom the unde rly ing hardwa r e . That i s , the ope r ating system sho ul d be impl ementabl e o n most cur rent and future hardware sy stems , and an appl ica t ion w r i tten in a standa rd high l evel language shoul d be abl e to r un on _any hardware sy s tem running unde r the control of s uch an operating sy stem .

Mo reover , a compute r cont rol l ed by a mode rn ope rating system shoul d be abl e to form pa r t of a ne two r k of di s t r ib uted compute r s , and pr ov ide use r s w i th eff ici ent , tr anspa r ent a cces s t o the r esour ce s avail abl e v ia the ne two r k . In pa r ti c ul ar , a modern o pe r ating sy stem sho ul d be abl e to make effect ive use of the l oosely-co upl ed mul t i-processo r sy stems that a r e begi nning to appear .

The cur r ent ge ne r a tion of widely- used, mul t i- use r , general-purpose ope rating sy stems have gradually evol ved f rom vers ions de s i gned in the 1 97 0 ' s and 1 96 0 ' s . Then , many of the i s s ue s that a r e of conside r abl e impo r tance today , wer e unimpo r tant o r not even tho ught of . I n pa r ticul a r , loosely- co upl ed mul t i--proce sso r sy stems we r e unf o r eseen , and ope rating sy stems we re de s i gned w i th a s ingl e-proce sso r mind s e t , making i t di f f i cul t t o po r t these systems to loosely- co upl ed mul t i-pr oce s so r s .

Fo r exampl e , c u r r ent impl ementa tions o f UNIX cannot even be po r ted to t i ghtly- co upl ed mul ti- proce s so r s w i thout maj or change s and pr eferably a compl e te r ew ri te [ 2 ] . The si tua t ion is even wo rse for loosely- co upl ed mul t i-pr o ce s so r s : the l ate st ' standard ' , UNIX Sy stem V [ 4 ] , al lows a rb i t r ary pr oce sses to share memo ry -which cannot be do ne eff ici ently on a l oosely-co upl ed mul t i- pr oce s so r . Fur thermo r e , the me ssage-pas sing mechani sm -wh ich is of cr i t i cal impo r tance to di s t r ibuted appl ica tions - is f a r too compl ica ted and c umbe r some to be impl emented eff ici ently . In fact , the de s i gne r s of thi s me s sage-passing mechanism have appa rently assumed that the sende r and r ece ive r pr oce sses share access to a common phy s i cal memo ry . There a r e also other aspect s of UNIX whi ch , upon clo se examinat ion , prove d i ff icul t o r impos sibl e t o impl ement ef fect ively on a loo sely- co upl ed mul ti-proce s so r .

The ·-si tua tion i s not much be tte r when one cons ide r s other w idely- used cur rent gene rat ion ope r ating systems . Thus , if one a ims to build a new compute r sy stem based on a loosely- co upl ed mul ti-pr oce sso r , a s ubs tant ial ope r ating sy stem devel opment effo r t mus t be unde r take n .

I f compa tibi l i ty with exi st ing sof twa r e i s one ' s pr inci pal co nce rn , one shoul d aim to impl ement ei ther a UNIX ' look-al ike ' , o r an MVS ' look-al i ke ' • However , as po inted out above , UNIX i s no t wel l s ui ted to the r ol e . The same is t r ue for MVS .

162

1 6 3

If , on the other hand , mak ing do w i th l imited r eso ur ces is one ' s pr incipal conce rn , then i t makes sense to develop a new operating system , with ful l use be ing made of what has been l ea rnt about ope rating systems since the 1 97 0 ' s .

The a uthor i s cur r ently invol ved in the devel opment of a loosely-coupl ed mul t i-microproce sso r system . The a im is that thi s sys tem should prov ide ' s uper main-frame ' funct ional ity and pe rformance . The proj ect is be ing unde r taken w ith relatively limited r esources , and bui lding a wo rking system w ith the available resource s is consi de r ed mor e impo r tant than prov iding compatibi l ity with some exi sting sof tware base . Conseq uently , a new ope rating system has been des i gned fo r thi s compute r , and a fai rly complete ' qui ck-and-di rty ' prototype has al ready been impl emented . A full- scale impl ementation , using the prototype ope r ating system as the development sy stem , is cur rently unde rway .

The r est of this paper i s a br ief s urvey of the main f eatur es of the ope r ating system de sign . The intention is not r igo rously to j ustify design decis ions , no r to po int o ut what contr ibution the wor k makes , but rather to prov ide the r eade r w i th an overall de scr iption and eno ugh detail to compar e the new ope rating system to any exi sting, operating system . A mor e de tailed de scr ipt ion can be found in [ 3 ] •

2 . PROCESSES

A new proce ss can be cr eated e i ther by fo r k ing an exi sting proce s s , in the sty le of UNIX , v ia the fol low ing two system cal l s : ( ' - > ' means ' r eturns ' )

fo r k_process ( pr,oce s s_num , moni tor ing_io_po r t ) -> process_num replace_image ( f il e_num , entry_point )

o r by loading the pr oce s s ' sta r ting image di rectly f rom a f il e : load_new_process

1

. ( f il e_num , monitor ing_io_por t ) -> process_num

The latte r method i s mo r e appropr i ate for a loosely- co upl ed mul ti-processor . It make s l ittl e sense to copy the cur r ent memory image of the pa r ent proce ss over the networ k to the processo r that is to execute the new s ubproces s , only to r epl ace i t soon af terwards with a new image obtained f rom a f il e , as is us ual ly the ca se . Fo rking i s only prov ided to faci l i tate UNIX compatibil ity .

Note that , unl ike UNIX , a process can for k not only itsel f , but al so one of its s ubprocesse s . Fur thermo r e , a pa rent process can be informed of al l sta te changes in i ts subproce sses , and can exe r t compl ete control ove r them , with the abil ity t o te rminate , suspend , o r resta r t a pa r ticul ar s ubprocess .

Fur thermo r e , unl ike UNIX , a new process · i s created in a s uspended state , and execution must be sta r ted expl ici tly by i ts pa rent . Th is al lows a proce ss to load sever al subprocesses and to set up communica tion l inks be tween them while they are in a known state .

A par ent process may al so s uspend an execut ing s ubprocess and then restart exe cution at a different inst r uction . The suspend/resta r t

164mechani sm i s fo rmul ated s uch that the resta r ted s ubproce ss can execute ei ther an inte r r upt handl e r ( event ually returning to the point of inte r r uption ) , or an except ion handl er ( never r eturning ) .

As is to be expe cted , a process can s uspend o r te rminate i tsel f and s upply a r ea son code that will be r ece ived by its par ent . A process can al so dynamical ly obta in additional memory f rom the operating system , and r el ease unused memo ry for use by other processes .

The operating sy stem does not no rmal ly allow processes to share access to the same a r ea of memo ry , s i nce , in general , it is not possibl e or des i rabl e to ensur e that proce sses execute on physi cal pr ocesso r s that have a ccess to a common physical memory bank . Memo ry shar ing i s therefor e di s co ur aged by l imiting i t to special ly pr ivil eged ' se rve r ' processes . ( Se rver processes a re discussed in Sect ion 4 . )

It is , however , po ssibl e to simul ate a fo rm of memo ry shar ing between different ' l ight-we ight ' processes exe cut ing on the same processo r by inco rpo rating a s chedul e r into the code of a single ' heavy-we ight ' ope r ating system pr ocess . Such ' l ight-weigh t ' schedul e r s can i gno r e mo st o f the fai rness , synch ronization, and secur ity issue s that an ope rating system must addr ess , and can thus prov ide a much cheape r form of singl e-pr ocesso r concur r ency than the ope rating sy stem . A typi cal user of ' l ight-weight ' processes wo ul d be a se rver process that must se rve several cl ients concu r r ently .

3 . INTER- PROCESS COMMUNI CATION

As Hoare poi nted o ut [ l ] , t ransfer r ing information f rom a process to a proce ss doe s not di ffer f rom transf er r ing information f rom a dev ice to a process , o r f rom a proce s s to a dev ice . In fact , in a modern oper ating system impl ementation, dev ice dr iver s a re l ikely to be impl emented by processes .

Consequently , the operating system prov ides a general iz ed I/0 call as the pr incipal means whereby processes must interact w ith thei r env i ronment . This system cal l co r r esponds to the cl assical I/0 cal l of cur r ent gene ration operating sy stems in most r espects , gene r al iz ing i t only in so far as to al low I/0 o perations to be pe rformed on processes as wel l as on ; f iles and dev ice s , and by al low ing .,a singl e operation to per fo rm both output and input .

The I./0 cal l is invoked as fol lows : i o ( io_po r t , ope ration , addres s ,

out_len , o ut_buf , in_len , in_buf )

No te that all the pa ramete r s , except out_buf , may be upda ted by the cal l .

An I/0 po r t co r r esponds to a UNIX f ile des cr iptor , but may repr esent another proce s s , as wel l as a f ile o r dev ice . fur thermo r e , up to si xteen di fferent I/0 oper ations may be

1 65 ca r r ied o ut on an I/0 po r t . Fo r exampl e , when an I/0 po r t i s l inked to a f il e , the fol l ow ing ope r ations a r e s uppo r ted :

0 = 1 = 2 = 3 = 4 = 5 = 6 = 7 =

read next str ing ( length given in in_len ) write next str ing ( length given in o ut_len ) read str ing a t of fse t f rom f il e sta r t ( given in address ) w r i te str ing a t of fse t f rom f il e sta r t append str ing a t end of f ile get cur r ent l ength of f il e ( r es ul t in in_len ) se t cur r ent l ength of f il e to l ength in o ut_len f lush updates to non-vol atile storage

As can be seen , some operations a r e input ope r ations , other s perform output , and st ill others do ne ither . I t is al so po ssibl e to have operations that perform output a s wel l as input . In gene r al , the subset of ope r ations that can ; be car r i ed o ut on an I/0 por t and the effect of the ope r ations depend on the kind of obj ect to whi.ch the I/0 po r t is 1 inked . When an I/0 po r t is used as an inter-proce s s communi ca tion l ink , the progr ammer has f ul l cont rol ove r the s ubset of al lowabl e ope r ations and the inte rpretat ion g iven to them .

An I/0 po r t i s l inked to a f il e , dev ice , o r server v ia : open ( process�nurn, io_por t , obj ect_num, des i red_ops )

-> avai l able

Note that a pro cess can open no t only its own I/0 po r ts , but also those of s ubproce s ses ; obj ect_nurn identi f ies the f ile/dev ice/se rver ; des i red_ops is a b itmap indi ca ting the s ubse t of the si xteen po ssibl e operations that the cal l e r wishes to ca r ry out on the I/0 po r t . ( Fo r exampl e , to open a f ile fo r seq uent ial read-only acce s s , des i red_ops must have a val ue of 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 . f.

An I/0 po r t i s 1 inked to a pro ce s s v ia : connect ( process_a , io_por t_a , bitmaps_a , t ime_out_a ,

pro cess_b , io_po r t_b , b itmaps_b , time_out_b )

A process may connect the I/0 po rts of its s ubpr ocesses to each other , o r may connect i ts own I/0 po r ts to the I/0 po r ts of subprocesses . Thus a process can communi ca te w i th i ts subprocesse s , s ibl ings , pa rent , and f iles/dev ices/s ervers .

No te that each I/0 po r t has a bi tmap associ ated w i th i t , indi ca ting which I/0 operations may b e car r i t··d o ut o n i t , as wel l as a bi trnap indicating whi ch I/0 ope ratic ,ns pe r form output . Addi tional ly , a time-out is associated w i t h each po r t . These

- val ues a r e expl ic i tly specif ied fo r po r ts o pened w i th connect , but a r e de te rm ined by the obj ect to which the po r t i s l inked for ports opened w i th open .

The gene ral progression of an I/0 cal l is a s fol lows :

send ope ration, address , out_len , in_len to the other process ( append contents of out_buf if the oper ation cal l s for i t )

- wait fo r a r esponse f rom the other proce s s ( r eturn w i th a n e r r o r code i f no r esponse within t ime_out )

1 /0 state t rans i t i on d iag ram

Process A Process B

i n it i a l state i n i t ia l state cal ls 1/0 to perform output

_;__ _ __.z.. ___ __

cal ls 1/0 to perform input

await i n g i n it i at ion . i n i t iat i ng 1 /0 A �ce1ves go-ahead � data j

___ _.;.. ____ B transmits i nput req u.�e,;;;,.;st _________ _ i n it i at i ng 1 /0 1/0 i ncom plete

I A transm its o ut�

ut requ e • I dala _ ___ .....;._____ ---------B receives response 1 /0 i ncom pl ete to input request response --------

18ut c�ll lJtuf re� b A ,,,,;;-__ ...,..._...::n..:.::;o�W..:..;;re;.:;.ce::.:..18��� as ,Xput by B

com pl ete

A receives response to 1/0 i n it i ati n g 1/0 < aara I

B transmits request fo r next 1/0 --------response avai labl

i ncom pl ete next 1 / .0 ca l ! A transmits req�t for next 1/0

I data :;_,;> ----------response avai lab l B receives response

1 /0 comp lete

Fig u re 1

next 1/0 cal l

1 6 6

167 - return ope ration , address , o ut_len , in_len sent by the other

process , and sto re rest of its r espom,e in in_buf ( sender out_len = rece iver in_len , and sender in_len = receiver o ut_len )

When a n I/0 po r t has j ust been connected t o another , the f i rst ope ration that outputs the contents of o ut_buf is del ayed until the other process per fo rms an input operation on i ts co r responding I/0 po r t . The I/0 cal l of the proces s that pe r fo rmed the input operation then compl ete s , returning the par amete r s and buf fer contents s uppl ied by the process that per fo rmed the output ope ration ( r es ul t ing in a data transfer tak ing pl ace ; see also f igure 1 ) . Meanwhile , the outputting I/0 cal l is s uspended while awaiting a r esponse . Thi s r esponse is r eceived when the process that per fo rmed the ini ti al input ope ration per fo rms its next I/0 ope ration . The r esponse consists of the par amete r s and possibly the contents of out_buf , s uppl ied to the second I/0 ope r ation .

Thus , two communi cating processes a r e always synch roniz ed so that the initiation of an operation by one , causes the compl etion of an ope ration by the other , as wel l as a data transfer . The resul t is that communication takes on a ' hand-shaked ' req ue st- response natur e , and that when one process sends o utput to another , the other has al ready set up an input buffer to the rece ive the transferred data . Thi s el imina tes the need fo r a sy stem buffer pool and takes ca re of flow-cont rol and synch roniz ation .

When a po r t i s opened to a f ile/dev ice/se rver , the operating system engage s in a · di alogue with a co r responding f il e-dr ive r-process/dev ice-dr iver-process/server-proce s s , which res ul t s in an inter-process communi ca tion l ink be ing set up be tween the cl ient process and a dr iver/server proce s s . After the open , the dr iver/server is waiting to compl ete an I/0 operation, and the cl ient process has yet to perform its f i rst oper ation. When the cl ient per forms i ts f i rst I/0 operation on the po r t , the incompl ete I/0 at the dr iver/server compl ete s , resul t ing in the dr iver/server r eceiv ing the r eq uest made by the cl ient . Af ter se rv ing the r eq uest , the dr iver/se rver responds by ini tiating a next I/0 oper ation, which in t urn causes the cl ient ' s incompl ete I/0 operation to compl ete , returning the de si red resul t s .

Natural ly , the I/0 cal l allows a proceed option ( indica ted by setting a modi f ier b it in operation ) . A proceed I/0 cal l sends the r equest to the other proce s s , but does not wai t to r eceive the response . The r equest ing process can later compl ete the cal l and receive the response by per fo rming another I/0 cal l on the po r t -· se tting a modi f ier b i t to indicate whether or not to wait fo r the

- response , if thi s has not yet been received .

It i s po ssible for a process to have a numbe r of I/0 por ts on which proceed I/0 operations were ca r r ied o ut . Therefo r e , it i s possibl e to pe rform an I/0 call that will complete any one of these incompl ete cal l s . This facil ity will typical ly be used by a server proce ss that se rves many cl ients concur r ently , and thus may be wai ting for several requests ( that i s , have several in compl ete I/0 cal 1 s ) a t the same time .

The I/0 cal l al so s uppo r ts broadcasting/mul t i- cast ing , as wel l as sca tter/gather transfers .

4 . SERVERS

Se rve r processes a r e the pr incipal means by whi ch the operating system prov ides i ts serv ices . Fur thermo r e , servers can be used as the bas i c blo c ks fo r bui lding d istr ibuted appl ications .

1 6 8

A server proce s s has a gl obally visibl e name , d rawn f rom the same name space used for f il es and dev ice s . Thus , a prospective cl ient establ ishes an inter-proce ss communi ca tion l ink w i th a server by cal l ing open . The ope r ating sy stem car r ies o ut a · cal l to open by sending an un sol ici ted message to the ta rge t of the open cal l . Whether i t i s a f il e , dev ice , o r expl ici t server , the ta rge t of an o pen cal l is alway s a proce s s ; hence the term ' se rver ' will f rom now on be unde r s tood to incl ude f iles and dev ices .

When a server sta r ts exe cut ing , i t sets up a number of ' r econf igur abl e ' I/0 po r ts , us ing :

make_reconf igurable ( io_po r t , val id_op_bi tmap, in_len , in_buf , t ime_out )

While r econf igurabl e , an I/0 po r t does not r epr esent a communi cation 1 ink to any pa r ticul a r- process , but acts a s a r ece iv ing po r t for unsol ici ted messages . Thus , when the operating system sends an un sol icited message to a server , one of the server ' s r econf igurabl e I/0 po r ts is sel ected to hol d the message , and the se rver will receive the message when it tr ies to compl ete an I/0 cal l on that po r t ( i t will us ual ly try to compl ete an I/0 cal l on any po r t ) . Note that make_reconf igurabl e sets up the buf fer to hol d the un sol ici ted message .

The unsol i c i ted message r ece ived by the server a ) can be tr usted beca use it comes f rom the operating system ; b ) ful ly ident i f ies the prospect ive cl ient , its priv ilege s , the

type of acce ss r eq ui red , and so on .

Af ter receiv ing s uch a message , the server must decide whether or no t to accept the cl ient and indi cate thi s by outputt ing an appr opr i ate mes sage th rough the I/0 po r t that r ece ived the r eq uest . If the cl ient is accepted , the I/0 cal l indicating the acceptance r emains incompl ete unt il the cl ient per forms its f i rst I/0 ope ration on the pQr t it has j ust opened s uccessful ly . Thus , when a cl ient i s accepted v ia a reconf igur abl e I/0 po r t , the I/0 po r t i s conf igur ed as a dedica ted inter-process communica tion 1 ink_ be tween cl ient and serve r . Note that , among other things , the server ' s a cceptance message suppl ies informa tion to be associated w i th the cl ient ' s I/0 po r t : the val id ope r ations , the operations that output out_buf , and the time-out to be used when wait ing f o r a response f rom the serve r .

A serve r pro cess can be tied to a pa r tic ular pro cessor of a mul ti-pr oces so r sy stem , in whi ch case i t is l oaded when that processor boot st r aps . Al ternatively , a se rver can be ' untied ' , in which case it is loaded into any avail abl e processo r when f i rst

16 9 r eferenced by an open cal l . Unt ied se rver s us ual ly terminate when they have no mo r e cl ients .

Des i gnat ing a process as a se rver , thus giv ing i t global vi sib;i l ity , is a pr iv ileged operation since a server is t r usted to take par t in the ' new cl ient ' protocol . Se rver s a r e al so the only class of proce sses that can be al l owed to pe rform cer tain pr iv il eged ope rations .

Fo r instance , a se rver that i s t i ed to a pa r ticul ar processo r can be used as a dev ice dr iver by allow ing i t the pr iv ilege to access I/0 spa-ce and to instal l inter r upt handl e r s . A t ied server can also be al l owed to share memory with other serve r s t i ed to the same pr oce sso r .

It fol lows that an impl ementation of the ope rating sy stem w ill itsel f largely consist of a set of server proce s se s di s t r ibuted among the var ious phy s i cal proce s so r s . Adding new servers to the col lecti on making up the bas i c operating sy stem w i l l be str aightforward , resul t ing in an ' open ' , extensibl e , adaptabl e ope r ating sy etem . Fur thermo r e , str uctur ing the ope r ating sy stem as a set of servers communi ca ting v ia mes sages gr eatly facil itates the t ranspa r ent integration of local reso urces ( se rv ice s ) with reso ur ce s avail able , v ia a ne two rk , f rom other sys tems .

The se rver mecnanism al so allows a singl e se rv ice ( that is , a s ingl e obj ect in the name space ) to be impl emented by several co-ope r ating proce s se s . One way to impl ement such a mul t i-process server is to designate several server processes as the membe r s of a singl e serve r · group, ident if ied by a singl e ' group obj ect ' numbe r . When a cl ient pe r forms an I/0 oper ation on an I/0 po r t 1 inked t o a group,, the r eq uest message i s broadca st t o all membe rs of the group . I t is po ssible for the str ucture of the group to be inv isible �o the cl h�nt , in which ca se the membe r s must use a pr otocol to ensur e t hat only one r esponse w i l l be gene r ated . Al ternatively , a cl ient may be requi red to be awar e of the group structu r e , in which case the cl ient must se t up addi tional I/0 po r ts to rece ive the mul t ipl e r esponses ( an I/0 po r t can rece ive at mo st one r esponse for each req ue st ) .

It i s al so po ss ibl e to impl ement a server gr oup , w i thout us ing broadcasting , by means of a co-ordinato r proce s s . In this case , cl ient req uests go to the co-ordinator , and the co-ordinator then ' s ubcontr act s ' them to the other proce sses co-ope rating to prov ide the serv ice . A co-o rdinator can s ubcont ract al l cl ient interaction , in which ca se the ' r eq uest to be come a cl ient '

message goes to the co-o rdinator and i s subcont racted , fol low ing which al l fur ther interact ion is be tween cl ient and s ubcontr actor ( unbeknown to the cl ient ) . Al ternatively , a co-ordinator can subcont r act indiv idual req uest s , in which ca se all req uests f i rst go to the co-ordinator and then to the subcontractor s .

Note that s ubcontract ing and broadcast ing can be combined . I t is thus po ssibl e to exploit mul tipl e pr oce s so rs to achieve both speed and faul t- tol erance , while prov iding cl ient s with the i llusion of deal ing w i th a s impl e ' singl e ' server .

5 . THE FILE SYSTEM

The f il e sy stem is intended to facil ita te the storage and r e t.r ieval of arbi trary str ings of bytes , s uch as text f iles , obj ect f iles , and proce s s images . The f il e system is not intended a s an eff icient o r convenient stor e for reco r ds s ince it i s mor e r easonabl e t o use a da tabase management system t o store and r etr ieve such da ta .

The f ile sy stem is impl emented a s a set of communica ting serve r s , with each open f il e hav ing a co r r esponding ' dr iver ' proce ss that actual ly r eceives and acts upon the I/0 operations that cl ient processes per fo rm on I/0 po r ts l inked ' di rectly ' to f iles . The f il e sy stem se rver s a r e str uctured a s a hierarchy and in s uch a way that the da taba se management sy stem can exist ' alongsi de ' the f ile sy stem , by making use of the lower l evel ' di s k bl o ck ' server s instead of the f il e system v isibl e a t system cal l level .

Fi l es a r e ident i f ied by number s d rawn f rom a global name space that incl ude s dev ices and serve r s . Th i s al lows user interfaces to use a rbi trary symbol i c name- to- f i l e numbe r mappings , fur ther adding to the ' open ' , extensibl e , adaptabl e natur e of the ope r ating sy s tem .

Files a r e al loca ted in two steps : c r ea te_temporary_f il e ( logical_vol_num , s iz e,:;__hint ) -> f il e_num make_f ile_pe rmanent ( fil e_num , future_expansion_hint )

Temporary f il es a r e a utomatical ly recl aimed when the process that allocated them term ina tes . By conver ting these tempo rary f il es into pe rmanent f il e s , rather than di rectly al locating permanent f iles , it i s po ssibl e to fol low a protocol that r es ul ts in the al loca tion of a f il e and the recording of a symbol ic name- to- file numbe r mappi ng as an atom ic ope r ation .

The size hint s that may be given when a f i l e i s al loca ted allow the ope rating sy stem to pr e-al loca te space fo r a f il e so that seq uent i al acce ss is optim iz ed . The f ile sy stem need not heed the hints and w il l never refuse to allocate or grow a f il e becaus e a s ui tabl e r un of disk bl ocks i s not avail abl e .

The des i gn o f the f il e sy stem attempt s t o minimiz e the v isibil ity of phy s i cal di s k vol umes to appl ica tion programmers in o rde r to promote progr am transpo r tabil ity : Al l pe rmanently on- l ine E tor age medi a a r e consol idated into logical vol ume zero and f il es f rom al l vol umes a r e identif ied f rom a singl e name space .

However , i t i s nece s sary to introduce the concept of d istinct vol umes to cope w ith removabl e d i s k packs . Cl early , the operating sy stem cannot j us t inco rpo r tate r emovabl e di sk packs into a global pool and al low arbi trary f il es to be al loca ted on r emovabl e d isk pa cks . Conseq uently , removabl e di sk packs a r e gr ouped into one or mo r e log i cal vol umes , any of which can be off- l ine . F ile al locations on these vol umes must be indi cated expl ici tly and can only be pe r formed by s ui tably autho r iz ed use r s .

6 . Secur ity

Use r s gain access to the operating system by inter act ing w ith a user authent i ca tion server . I t i s po ssible to a s sociate an a rb i trary authent i ca tion se rver w i th a given use r acce s s dev ice , and to r est r i ct a given se rver to adm itting only a s ubset of users . Thus , it is po ss ible to make it r easonably easy to gain entry as a ca s ual use r , whil e making it arbitrar ily d i f f icul t to gain entry as a pr iv il eged us er .

When a use r ga ins entry into the sy stem , the co r responding user acce ss dev ice i s a s s i gned to an appropr iate use r interface process , which i s ' executing on behal f of ' the use r . The ' executing on behal f of ' prope r ty of a process i s inher i ted by al l s ubprocesses , and can only be changed i f a process i s a specially pr iv il eged server pro cess ( fo r exampl e , an a uthent i cation serve r ) . Thus , al l act ions initiated by a use r are ca r r ied o ut by proce sses· a uthent ical ly execut ing on behal f of the use r .

F i les , dev ice s , and serve r s al l �ave owner s , and a r e accessibl e only to pr.oce s ses execut ing on behal f of the owne r o r a use r expl icitly · mentioned in an access l ist - a f il e l ist ing al l the user s that may acce s s the protected obj ect , with each ent ry indi ca ting an indiv idual set of pr iv ilege s for the use r . ( Note that a server may rej ect a cl ient even if the cl ient is l isted in its acce s s 1 is t . )

Addi tional ly , · f il es , dev ices , serve r s , and processes a r e associ ated w ith ' info rmation catego r i es ' . An a rb i tr ary numbe r o f info rmation ca tego ries can b e establ ished , and t h e ope r ating sys tem enfo rces a set of r ules that ensur e that information cannot ' flow ' f rom one ca tego ry to another , unl ess specif ical ly pe rmitted . This is bas i cally ach ieved by l im iting a pr ocess to access ing only obj ects associated w ith the same information catego ry , while al so al low ing a proce s s to have r ead-only access to obj ects associated w ith ca tego r ies that have flow pa ths to the ca tego ry of the process . A proce s s may only change i ts ca tego ry if its use r is permitted to ope rate in the new ca tego ry and if the

· change cannot resul t in an i l l egal flow of information .

The ope rating sy stem al so incl ude s mechani sms for l im i ting sof twa r e pi racy , denial of resour ces , Troj an Ho rse a ttac ks , and the use of cover t channel s to subver t information flow cont rol s .

7 . DATABASE SUPPORT

._ Da tabase mana ge r s a r e pr incipally s uppo r ted by the server mechanism . Fur thermo r e , the f ile sy stem is structured in such a way that a database manage r can acce s s di sk bl ocks di rectly .

The only addi tional s uppo r t prov ided by the operating sy stem is in the form of a t ransact ion co-ordinating server . Thi s server is a ccessed by cl ient processes v i a the sy stem cal l s :

s ta r t_transaction commit_tr ansaction -> s uccess_ind i ca tor abandon_t r ansaction

172 These cal l s keep the transaction co-ordinator up to da te on the transa ct ion status of proce s se s , and i t , in t urn , keeps ' tr ansa ct i on suppo r ting ' s e rve r s up to date on the transact ion s ta tus of thei r cl ient s .

The transaction co-ordina to r co-ordinates a two-phase commit , prov ides a ' cent r al iz ed ' deadl ock de tect ion serv ice , and allows t ransaction s uppo r ting s e rver s to use a wide range of synch roniz ation strategies , incl uding optim istic st rategi es .

Whil e i t i s logi cal ly a central iz ed serv ice , the tr ansaction co-o rdinator can be impl emented a s · a distr ibuted set of co-ope rating proce s se s , and thus doe s not pr ecl ude the impl ementa tion of a distr ibuted da tabase manage r .

8 . REAL- TIME SUPPORT

The ope r ating sy stem al l ows the m inimum rate of execution of a process to be specif ied di rectly rather than be , inf l uenced indi rectly by means of pr io r i ties . Fur thermo r e , processes a r e cl assed as ' r eal- time ' o r ' o rdinary ' , with real- time processes pr e-empting o rdinary pro ce s ses . Al l operating sy stem server processes execute as o rdina ry pro ce s ses , thus giv ing r eal- t ime appl ication programmer s compl ete control ove r proce s sor al location .

Note al so that server pr ocesses can be gr anted. the pr ivilege of handl ing inte r r upt s di rectly , as wel l as to . share memo ry with s imilar se rve r s on the same processo r . Fur thermor e, the operating sys tem can be conf igured w ith a separate ' real- time ' f il e system that serves only real-time processes and thus isolates r eal- time pr ocesses f rom inter fer ence by non- real-time proce s ses in this aspect as wel l .

9 . CONCLUSION

Th is pape r has br iefly outl ined the design of an operating sy stem that is hardwar e independent , pr ov ide s a high l evel of da ta secur i ty , and s uppo r ts di str ibuted appl ications , da tabase appl ica tions , as wel l as r eal-time appl ications .

Th is has no t been achieved by int roducing radically new concept s , but by ca r ef ul ly refo rmul ating , general iz ing , and integrating the bas i c concepts that any ., operating sy stem mus t suppo r t .

Fi rstly , the process concept has been st r ipped of rest r ictions and ass umptions , l eav ing a straightforwa rd mechanism that can be ut il iz ed e f f ic i ently for a w ide range of appl ica tions . Secondly , the input/o utput mechanism has been general iz ed to prov ide a straightforward , ef f ic i ent fo rm of inter-process communica t ion . Th i rdly , the concept of a dev ice has been general ized into the concept of a server , on whi ch the ope r ating sy stem itsel f is l argely based . Se rve r s make the operating sys tem flexible and extendibl e , and prov ide a sui tabl e mechanism for di str ibuted impl ementa tions .

1 7 3 REFERENCES

[ 1 ] Hoa r e , C . A . R. Communi ca ting Sequenti al Pro ce s ses Commun i ca tions of the ACM, 2 1 ( 8 ) , August 1 978 , pp . 6 6 6-6 7 7

[ 2 ] Jannsens , M . D . , Anno t , J . K . and Van de Goo r , A . J . Adapt ing UNIX for a mul tiproce sso r env i ronment Communi ca ti ons of the ACM , 2 9 ( 9 ) , September 1 98 6 , pp . 8 9 5-9 0 1

[ 3 ] Vente r , B . H . The De s i gn o f a new gene ral-purpose ope rating system Ph . D . Thesi s , Univer s i ty of Po r t El i zabeth, Apr il 1 98 7

[ 4 ] XELOS Progr ammer Reference Manual Pe r kin-El mer Co rpor ation , New J e rsey , 1 98 4

�