Betriebssysteme 1.1

1 The Xinu-Approa h

1.1 Operating Systems

� The software that ontrols pro esses, manages resour es and ommuni ates with

external devi es like disks and printers is alled an operating system.

� Operating systems allow multiple users to share the ma hine

simultaneously, prote t data from unauthorized a ess, and keep dozens of

independent devi es operating orre tly. The operating system is itself a

program that is exe uted by the same pro essor that exe utes user's programs {

if the ma hine is exe uting a user's program, the operating system is ina tive.

� An operating system manages to provide reasonably high-level servi es with

unreasonably low-level hardware.

� Operating systems hides the low-level details of the real ma hine, and provide

the high-level servi es of an abstra t ma hine.

1

Betriebssysteme 1.1

Operating Systems: Layering

� Resear h identi�ed the abstra t servi es ommon to all operating systems,

and explored their variations. The basi operating system omponents that

arry these ma hine-independent abstra tions have been formulated.

� Resear hers dis overed a te hnique alled layering the organized omponents

whi h simpli�es system design and eases implementation.

� At the heart of the layered organization is the raw ma hine. Subsequent layers

of software provide more powerful primitives, and shield the user from the

ma hine beneath.

� Ea h layer of the system provides an abstra t resour e, implemented in

terms of the abstra t servi es provided by lower level layers.

2

Betriebssysteme 1.2

1.2 Our Approa h

� The Xinu-approa h is a pra ti al approa h, showing the details of a real

system; starting with a mi ro omputer and pro eeding step-by-step through the

onstru tion of a layered system.

� You an see how an entire system �ts together, there's no mystery about any

part of the implementation, it's possible to experiment with the system.

� The programs and ode form an integral part of the book and the le tures,

beginning with a layering s heme and following it onsistently.

� The design ends with a omplete, working system that supports multiple

pro esses and a �le system.

3

Betriebssysteme 1.3

1.3 What an Operating System is not

1. A language or a ompiler: One needs no spe ial language or ompiler to write

an operating system.

2. Command interpreter: in modern systems ommand interpreters an be

hosen by users { or be written to meet their needs.

3. Library of ommands: Programs that edit �les, send mails, ompile programs

are just utility programs.

4

Betriebssysteme 1.4

1.4 An Operating System viewed from the Outside

� The essen e of an operating system are the servi es it provides to user

programs; programs a ess these servi es by making system alls.

� System alls look like pro edure alls appearing in ordinary programs, but

transfer to the operating system routines when invoked at run-time.

� These system alls establish a boundary between the running program and the

operating system, an operating system an even be des ribed by its servi es.

� The Xinu operating system des ribed in Comer's book we reads hara ters

from a keyboard, displays hara ters on a terminal, operate timers, saves �les on

disks, relays messages between programs, . . .

5

Betriebssysteme 1.4

1.4.1 The Xinu Small Ma hine Environment

Sometimes omputers are too small to ompile operating systems. How to get an

operating system on the omputer?

� There's a minimum on�guration on the mi ro omputer, alled the lient.

� The entire system is prepared on a larger ma hine, alled a host.

� Compilation is done on host with a ross- ompiler that runs on the host and

produ es ode for the lient.

� A downloader opies the memory image to the lient (over a serial onne tion).

� The exe ution pro eeds on the lient without the help of the lient.

Otherwise, one version of the operating system an be used to reate the next

version, this is alled bootstraping.

6

Betriebssysteme 1.4

1.4.2 Xinu servi es

Programs running under Xinu a ess servi es by alling operating system

routines through system alls. For example the system routine put writes a

hara ter on an I/O devi e. It takes tow arguments: the devi e identi�er and the

hara ter to write.

/* ex1. - main */

#in lude < onf.h>

/*-------------------------------------------

* main -- write "hi" on the onsole

*--------------------------------------------

*/

main()

{

put (CONSOLE, 'h'); put (CONSOLE, 'i');

put (CONSOLE, '\r'); put (CONSOLE, '\n');

}

7

Betriebssysteme 1.4

Example ex1.

The ode on the previous slide introdu es several onventions:

� ex1. is the name of the �le, the omment /* ex1. - main */ gives the

name followed by the pro edure de�ned by the�le, in this ase main.

� #in lude < onf.h> in ludes a �le of on�guration de larations in the sour e

program. This on�g �le ontains a de�nition for CONSOLE, wit h refers to a

terminal onne ted to the omputer through whi h the user intera ts. For now

we only need to know that this in lude statement must appear in every

program that uses devi e names.

� Four hara ters are written to the terminal: "h", "i", arriage return ("\r") and

a line feed ("\n"). The latter two are ontrol hara ters.

8

Betriebssysteme 1.4

1.4.3 Con urrent Pro essing

� Conventional programs are alled sequential be ause the programmer imagines

a ma hine with a single pro essor exe uting the ode statement-by-statement

without interruption or delay. In ontrast, on urrent pro essing means that

many omputations pro eed \at the same time".

� The most visible on urren y, multiple independent programs exe uting

simultaneously, is a grand illusion! To reate that illusion, the operating

system swit hes a single pro essor among multiple programs, allowing it

to exe ute one for only few millise onds before moving on to another one.

This is done at the lowest level of the operating system by the s heduler.

� Viewed by a human the pro esses appear to pro eed on urrently. This te hnique

is alled multiprogramming. Intera tive multiprogramming systems are alled

timesharing systems, when the poli y used to swit h the pro essor around

gives all users equal amounts of CPU time.

9

Betriebssysteme 1.4

1.4.4 The Distin tion between Programs and Pro esses

� The operating system swit hes the CPU among many omputations, alled

pro esses (jobs, tasks).

� At any time several pro esses may be exe uting. It may be that no two of

them are exe uting the same program, but it may also be that all are exe uting

the same statement of the same program.

� Sin e the pro essor is swit hed amongst pro esses, one pro ess may overtake

another; no guarantee is made about their relative speeds.

� Therefore the system pro edures must be designed so that ooperation between

pro esses fun tion orre tly, independently of their relative speeds; the following

example illustrates this:

10

Betriebssysteme 1.4

/* ex2. - main, prA, prB */ /*----------------------------------

* prA -- repeatedly print 'A'

#in lude < onf.h> * without ever terminating

*-----------------------------------

/*------------------------------------------------ */

* main -- example of reating pro esses in Xinu prA()

*------------------------------------------------- {

*/ while(1)

main() put (CONSOLE, 'A');

{ }

int prA(), prB();

/*----------------------------------

resume( reate(prA, 200, 20, "pro 1", 0)); * prB -- repeatedly print 'B'

resume( reate(prB, 200, 20, "pro 2", 0)); * without ever terminating

} *------------------------------------

*/

prB()

{

while(1)

put (CONSOLE, 'B');

}

11

Betriebssysteme 1.4

Explanation for example ex2. (1/2)

� The operating system starts up a single pro ess exe uting the user's main

program alled main().

� When a pro ess reates a new one by alling the system pro edure reate, the

original pro ess ontinues to exe ute and the new pro ess is ready to exe ute

on urrently.

� That single pro ess exe utes a all to system pro edure reate, passing the

address of prA (and prB) as �rst argument { the other arguments of reate

identify the sta k spa e needed for the pro ess reated, its priority, the name of

the pro ess, the number of arguments and the pro ess' arguments. Ea h all to

reate forms a new pro ess that begins exe uting instru tions at the address

spe i�ed by its �rst argument.

12

Betriebssysteme 1.4

Explanation for example ex2. (2/2)

� reate sets up the pro ess, ready to run, but temporarily suspended. It

returns the pro ess id (an integer that identi�es the reated pro ess) of the new

pro ess to its aller. The system pro edure resume starts (unsuspends) that

pro ess so that it begins exe uting.

� In this example, the �rst new pro ess prints A ontinuously, the se ond one prints

B ontinuously. Be ause he pro esses exe ute on urrently, the output is a

mixture of As and Bs.

� What happens to the initial pro ess exe uting the main programm? It exists

after the se ond all to resume, not a�e ting the newly reated pro esses at all.

13

Betriebssysteme 1.4

The Distin tion between normal Pro edure Calls and Pro ess Creation

� A pro edure all does not return until the alled pro edure ompletes.

� reate and resume return to the aller after starting the pro ess, allowing

exe ution of both the alling pro edure and the named pro edure (e.g. prA, prB)

to pro eed on urrently.

14

Betriebssysteme 1.4

Example ex3.

� The next example shows that independent pro esses need not exe ute

independent ode. A single pro ess begins exe uting the main program, alling

reate twi e to start new pro esses; both exe ute ode for the same pro edure

prnter( h).

� This points to the diÆ ulty involved in designing operating systems: Not only

must ea h pro ess exe ute orre tly by itself, it should also not interfere

with other pro esses (unless expressly stated), no matter how many pro esses

exe ute simultaneously.

� Although pro esses share ode, they usually have some lo al variables. reate

allo ates a independent set for ea h pro ess, as indi ated. This pro esses are

passed di�erent arguments, although exe uting the same ode.

� The �rst new pro ess reated by a all to reate is passed A as argument, so it

begins exe ution with formal parameter h set to A. The se ond new pro ess

begins with h set to B. Although these pro edures exe ute the same ode, ea h

has its own opy of h, just as re ursive invo ations of pro edures habe their

own opy of formal parameters. The output is a mixture of As and Bs.

15

Betrieb

ssy

stem

e1

.4

/*

ex3.

-main,

prntr

*/

#in lude

< onf.h>

/*--------------------------------------------------------

*main

--

example

of

2pro esses

exe uting

the

same

ode

* on urrently

*--------------------------------------------------------

*/

main()

{

int

prntr();

resume(

reate(prntr,

200,

20,

``print

A'',

1,

'A'));

resume(

reate(prntr,

200,

20,

``print

A'',

1,

'A'));

} /*--------------------------------------------------------

*prntr

--

print

a hra ter

*--------------------------------------------------------

*/

prtr(

h

)

har

h;

{

while

(1

)

put (CONSOLE,

h);

}

16

Betriebssysteme 1.4

Some more di�eren es between Programs and Pro esses

1. A program onsist of ode exe uted by a single pro ess. In sharp ontrast,

pro esses are not uniquely asso iated with a pie e of ode: multiple

pro esses an exe ute the same ode simultaneously.

2. Storage for lo al variables and pro edure arguments is asso iated with the

pro ess exe uting the pro edure, not with the ode in whi h they appear.

Therefore, ea h pro ess has its own sta k of lo al variables, formal parameters

and pro edure alls.

17

Betriebssysteme 1.4

1.4.5 Pro ess exit

� In the above example (ex3. ), the initial pro ess eased when it rea hed the end

of the ode of the main program; this is referred to as pro ess exit. Other

pro esses exit by rea hing the end of the pro edures in whi h they start (or

by returning from it). On e a pro ess exits, it disappears forever.

� Just like a sequential program, ea h pro ess has its own sta k of pro edure

alls. Whenever it exe utes a all, the alled pro edure is pushed onto the sta k;

whenever it return from that pro edure, it is popped of the sta k. Pro ess exit

o urs only when the pro ess pops its last pro edure (or main program) o�

the sta k.

� System all kill(P) terminates the pro ess with pro ess identi�er P. So a

pro ess may exit by alling kill(getpid()) { the all to getpid() returns its

pro ess id, wit h is passed on to kill.

18

Betriebssysteme 1.4

1.4.6 Shared memory

� In Xinu ea h pro ess has its own opy of lo al variables, formal parameters

and pro edure alls. But pro esses an also share a set of global (external)

variables { all pro esses have a ess to those variables.

� Example x4. demonstrates this: It's alled the produ er- onsumer-problem.

In the ode, global variable n, it is a shared integer, initialized to 0.

{ The pro ess exe uting produ e loops 2,000 times, in reasing n; it is alled the

produ er.

{ The pro ess exe uting onsume also loops 2,000 times; it prints the value of n

in de imal. We all this pro ess the onsumer.

� What happens when ex4. is run under Xinu? Will it print all values of n?

?

19

Betriebssysteme 1.4

Produ er-Consumer-Problem x4.

� A tually, it prints a low value of n, say 0, and then 2000. Why?

� Even though the two pro esses run on urrently, they do not require the same

amount of time. The produ er is fast, however the onsumer qui kly �lls the

available output bu�ers for printing the values of n. So the onsumer has to wait

for the output devi e to send hara ters to the onsole before it an pro eed.

While the onsumer waits the produ er runs.

� A onstraint is: How an the programmer syn hronize produ er and onsumer,

so that the onsumer re eives every datum produ ed?

{ The produ er must wait for the onsumer to a ess the datum.

{ The onsumer must wait for the produ er to manufa ture it.

20

Betrieb

ssy

stem

e1

.4

/*

ex4.

-main,

produ e,

onsume

*/

int

n=0;

/*

external

variables

are

shared

by

all

pro esses

*/

/*--------------------------------------------------

*main

--

example

of

unsyn hronised

produ er

*and

onsumer

pro esses

*---------------------------------------------------

*/

main()

{

int

produ e(),

onsume();

resume(

reate( onsume,

200,

20,

" ons",

0));

resume(

reate( onsume,

200,

20,

"prod",

0));

} /*--------------------------------------------------

*produ e

--

in rement

n2000

times

and

exit

*---------------------------------------------------

*/

produ e()

{

int

i;

for(

i=1

;i<=2000

;i++)

n++;

} /*--------------------------------------------------

* onsume

--

print

n2000

times

and

exit

*---------------------------------------------------

*/

onsume()

{

int

i;

for(

i=1

;i<=2000

;i++

)

printf("n

is

\%d

\n",

n);

}

21

Betriebssysteme 1.4

1.4.7 Syn hronization

� However the me hanism for implementing this waiting of produ er and

onsumer, alled syn hronization, should be designed arefully.

� In a single pro essor system, no pro ess should use the CPU while

waiting for another pro ess.

� Exe uting instru tions while waiting for another pro ess is alled busy waiting.

It should be ex luded on single-pro essor implementations be ause it auses

unne essary delays. Xinu avoids busy waiting by supplying oordination

primitives alled semaphores and system alls wait(s) and signal(s)

operating on a semaphore s:

{ The system all wait(s) de rements the semaphore s and auses the alling

pro ess to wait if the result is negative.

{ The system all signal(s) in rements s { if there's a pro ess waiting for s,

it's allowed to ontinue.

22

Betriebssysteme 1.4

Produ er-Consumer-Problem ex5.

� To syn hronize produ er and onsumer, two semaphores are needed:

{ One for leaving the onsumer wait on a value produ ed.

{ One for leaving the produ er wait until the onsumer is �nished with the

value just produ ed.

� Semaphore s is reated by system all s reate(n) whi h takes the desired

initial ount as an argument, returning an integer s by whi h the semaphore is

known.

� The modi�ed version of the produ er- onsumer-problem ex5. using two

semaphores now prints all values from 0 to 1999.

23

Betrieb

ssy

stem

e1

.4

/*

ex5.

-main,

prod2,

ons2

*/

int

n=

0;

/*

nassigned

an

intial

value

of

zero

*/

/*------------------------------------------------------

*main

--

syn hronized

produ er

and

onsumer

pro esses

*------------------------------------------------------

*/

main()

{

int

prod2(),

ons2();

int

produ ed,

onsumed;

onsumed

=s reate(0);

produ ed

=s reate(1);

resume(

reate( ons2,

200,

20,

" ons",

2,

onsumed,

produ ed)

);

resume(

reate(prod2,

200,

20,

"prod",

2,

onsumed,

produ ed)

);

} /*----------------------------------------------------

*prod2

--

in rements

n2000

times

(with

semaphore)

*----------------------------------------------------

*/

prod2( onsumed,

produ ed)

{

int

i;

for(i=1

;i<=2000

;i++){

wait( onsumed);

n++;

signal(produ ed);

}

} /*----------------------------------------------------

* ons2

--

print

n2000

times

(with

semaphore)

*----------------------------------------------------

*/

ons2( onsumed,

produ ed)

{

int

i;

for(

i=1

;i<=2000

;i++){

wait(produ ed);

printf("n

is

\%d

\n",

n);

signal( onsumed);

}

}

24

Betriebssysteme 1.4

1.4.8 Mutual ex lusion

� Assume two pro esses willing to print lines. Now a printer an only serve one

pro ess at a time. Clearly we do not want that these lines are interleaved on

the printer { we want ea h of these pro esses to have ex lusive a ess to the

printer, as long as their �le is printed.

� These two pro esses should engage in mutual ex lusion when ooperating so

that only one of them obtains a ess to a resour e at a given time. This an

also be realized using semaphores.

� For example, look at the problem of updating a list or an array whi h is

shared among a number of pro esses: Allowing simultaneous a ess would result

in an unde�ned out ome of the operation { so any pro ess operating on that

list or array should obtain ex lusive a ess to it to guarantee mutual

ex lusion.

25

Betriebssysteme 1.4

Mutual ex lusion example

Assuming that a pro ess reated a semaphore mutex using s reate before any

pro ess alls additem, the pro edure additem an be used to safely update an array.

/* ex6. - additem */

int mutex; /* assume initialized with s reat */

int a[100℄;

int n=0;

/*-------------------------------------------

* additem -- obtain ex lusive a ess to

* array 'a' and add item to it

*-------------------------------------------

*/ additem(item) {

wait(mutex);

a[n++℄ = item;

signal(mutex);

}

26

Betriebssysteme 1.5

1.5 A layered Operating System

� Xinu is designed in layers. The system fun tions are partitioned in roughly eight

major omponents, organizing those omponents into a layered hierar hy.

� Layering the omponents of an operating system is only done to make their

design and implementation leaner. It does not des ribe ontrol- ow.

On e �nished, the operating system an be alled using system pro edures in any

order.

� The hardware lies beneath the lowest layer, the user's programs run above

these eight layers.

27

Betriebssysteme 1.5

The layering of omponents in Xinu

1. At the system's heart is the s heduler and ontext swit h: They swit h the

CPU among pro esses ready to run.

2. The next layer onstitutes the rest of the pro ess manager { providing

primitives to reate, kill, suspend and resume pro esses.

3. In the pro ess oordination layer semaphores are implemented.

4. Message passing is implemented in the interpro ess ommuni ation layer.

5. The real-time lo k manager s hedules pro esses and delays them (for a given

time).

6. On the top of the real-time lo k layer lies a layer of devi e manager and

devi e drivers, where the devi e-independent input and output routines are

implemented.

7. The layer above the devi e manager implements ma hine-to-ma hine

ommuni ation, so alled interma hine ommuni ation.

8. The �le system is ontrolled by the last layer.

28

Betrieb

ssy

stem

e1

.5

Th

elayerin

gof

om

pon

en

ts

in

Xin

u

HA

RD

WA

RE

ME

MO

RY

MA

NA

GE

RP

RO

CE

SS

MA

NA

GE

RP

RO

CE

SS

CO

OR

DIN

AT

ION

INT

ER

PR

OC

ES

S C

OM

MU

NIC

AT

ION

RE

AL−

TIM

E C

OLC

K M

AN

AG

ER

DE

VIC

EM

AN

AG

ER

AN

D D

EV

ICE

DR

IVE

RS

INT

ER

MA

CH

INE

NE

TW

AO

RK

CO

MM

UN

ICA

TIO

NF

ILE

SY

ST

EM

US

ER

PR

OG

RA

MS

29