Post on 21-Jul-2016
description
transcript
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,
A'',
1,
'A'));
resume(
reate(prntr,
200,
20,
A'',
1,
'A'));
} /*--------------------------------------------------------
*prntr
--
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
--
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
--
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