Operating Systems. 2. A resource manager! What is an operating system?

(1)

394

Oper

at

ing Syst

ems

alian National Uni

versity

page 394 of

489

(c

hapter 7: “Oper

ating Systems” up to page 436)

W

hat is an oper

ating system?

2. A resourc

e manag

er!

... coordinating access to hardw

are resources

Operating systems deal with • processors • memor

y • mass storag e • communication channels •

devices (timers, special purpose processors, peripheral hardw

are, ...)

G

and tasks/processes/programs which are applying f

or access to these resources!

391

Oper

at

ing Syst

ems

versity

page 391 of

489

(c

hapter 7: “Oper

W

hat is an oper

ating system?

1. A vir

tual machine!

... of

fering a more comf

or

table and saf

er environment

(e.g. memor

y manag

ement and protection, hardw

are abstraction, process manag ement, inter -process communication, ...) 388

7

Oper

ating Systems

Uwe R. Zimmer -

T

he

A

ustr

alian National Uni

versity

C

omput

er Org

anisat

ion & Prog

ram Ex

ecut

ion 2021

395

Oper

at

ing Syst

ems

versity

page 395 of

489

(c

hapter 7: “Oper

T

he e

volution of oper

ating systems

•

in the beginning: single user

, single program, single task, serial processing - no OS

•

50s: System monitors / batch processing G

the monitor ordered the sequence of jobs and trig

g

ered their sequential e

xecution

•

50s-60s: Advanced system monitors / batch processing: G

the monitor is handling inter

rupts and timers

G fi rst suppor t f or memor y protection G fi rst implementations of privileg

ed instructions (accessible by the monitor only).

•

early 60s: Multiprogramming systems: G

employ the long device I/O delays f

or switches to other

, runable programs

•

early 60s: Multiprogramming, time-sharing systems: G

assign time-slices to each program and switch regularly

•

early 70s: Multitasking systems – multiple dev

elopments resulting in UNIX (besides others)

•

early 80s: single user

, single tasking systems, with emphasis on user inter

face or APIs.

MS-DOS, CP/M, MacOS and others fi

rst employ

ed

‘small scale’

CPUs (personal computers).

•

mid-80s: Distributed/multiprocessor operating systems - modern UNIX systems (S

Y S V , BSD) 392

Oper

at

ing Syst

ems

versity

page 392 of

489

(c

hapter 7: “Oper

W

hat is an oper

ating system?

1. A vir

tual machine!

... of

fering a more comf

or

table and saf

er environment

Hardw

are

OS

Tasks

Typ. g eneral OS

Hardw

are

R T-OS

Tasks

Typ. real-time system

Hardw

are

Tasks

Typ. embed ded system run-time environment 389

Oper

at

ing Syst

ems

versity

page 389 of

489

(c

hapter 7: “Oper

Refer

ences for this c

hapter

[P atter son17] David A. P atterson & J ohn L. Hennessy C omput er Org anizat

ion and Design – The Hardware/Sof

tware Int er fac e Chapt er 4 “The Proc essor ”, Chapt er 6 “P ar allel Proc essor s from Client t o Cloud”

ARM edition, Morgan Kaufmann 2017

396

Oper

at

ing Syst

ems

versity

page 396 of

489

(c

hapter 7: “Oper

Types of curr

ent oper

ating systems

P

ersonal computing systems, w

orkstations, and w

orkgroup ser

vers:

• late 70s: W orkstations star ting by por ting UNIX or VMS to ‘smaller’ computers. • 80s: PCs star

ting with almost none of the classical OS-f

eatures and ser

vices,

but with a user

-inter

face (MacOS) and simple device driv

ers (MS-DOS)

G

last 20 y

ears: ev

olving and e

xpanding into cur

rent g

eneral purpose OSs, lik

e f or instance: • Solaris (based on S VR4, BSD , and SunOS) •

LINUX (open source UNIX re-implementation f

or x86 processors and others)

•

cur

rent Windows (used to be par

tly based on Windows NT

, which is ‘related’ to VMS) • MacOS (Mach k

ernel with BSD Unix and a proprietar

y user

-inter

face)

•

Multiprocessing is suppor

ted by all these OSs to some e

xtent.

•

None of these OSs are suitable f

or embed

ded systems, although trials hav

e been per

formed.

•

None of these OSs are suitable f

or distributed or real-time systems.

393

Oper

at

ing Syst

ems

versity

page 393 of

489

(c

hapter 7: “Oper

W

hat is an oper

ating system?

2. A resourc

e manag

er!

... coordinating access to hardw

are resources

390

Oper

at

ing Syst

ems

versity

page 390 of

489

(c

hapter 7: “Oper

What is an oper

(2)

403

Oper

at

ing Syst

ems

versity

page 403 of

489

(c

hapter 7: “Oper

Types of curr

ent oper

ating systems

Star t-stop system Ar tw ork by Q

. Mehdi (cc attribution license)

t SSt Cylinder deactivation K ey identifi cation ABS ESC HUD Lane holding Adaptiv e cruise control Cross traffi c detection Navigation system Adaptiv e dampers Displays Dashboard Airbags Alarm system A/C Driv er monitoring A utomated Wipers A utomated Lights Black Bo x P o w er manag ement Seat adjustments Hill star t assist Transmission control Window control Interior lights Engine/motor manag ement hb d Speech recognition Night vision d Mir ror dimming Tail gate Seat heating Emerg enc y brak es dW i Wi Steering P o w er reg eneration Bl Enter tainment system l Radar/Lidar sensing Imag e processing A utomated parking Traction control T

ire pressure sensors

Emerg enc y ser vices call Blindspot detection 400

Oper

at

ing Syst

ems

versity

page 400 of

489

(c

hapter 7: “Oper

Types of curr

ent oper

ating systems

Real-time operating systems

• Fast conte xt switches? should be fast an yw ay • Small siz e? should be small an yw ay • Quick response to e xternal inter rupts? not ‘quick’ , but predictable • Multitasking? of

ten, not alw

ays • ‘low lev el’ programming inter faces? needed in man y operating systems •

Interprocess communication tools?

needed in almost all operating systems

•

High processor utilization?

fault tolerance builds on redundanc

y! 397

Oper

at

ing Syst

ems

versity

page 397 of

489

(c

hapter 7: “Oper

Types of curr

ent oper

ating systems

P

arallel operating systems

•

suppor

t f

or a larg

e number of processors, either:

•

symmetrical: each CPU has a full copy of the operating system

or •

asymmetrical: only one CPU car

ries the full operating system, the others are

operated by small operating system stubs to transf

er code or tasks. © 2021 U we e R. Zi mmer , T h e A ustr a tr lian Nat lian Nat ional Un ional Un iv ersity iv ersity page 397 of y y 489 (c hapter 7: “Oper

9

•

symmetrical: each CPU has a

full copy o f the operatin g system o r ••••••••• asym asym asy asy asym asyasasymasyasyma asym y metr metr metr metr metrme etr ical ical icalical ical ica : on : on : on : on : on o ly o ly o ly o ly o ly o y o ne C ne C ne C ne Cne C C PU c PU cPU c PU c PU c PU c ar ri ar ri ar ri ar ri ar r ar ri es t es t es t es t es t es t he f he fhe he fhe f he f e ull ull ull ull ull uull oper oper operoper ope oper pe atin atin atin atin ati a g sy g sy g g syg syg stem stem stem , th , th , th e ot e ot e ot ttt hers hershershershershers hers hershershers hers hhershersh ersersers rsrs are are arareaarearearaareaararaar are ar rrrrr oper oper oper oper operoperoperoperoperoper p aatedated ated atedated ated ate e by by by by by b y smalsmasmal smalsmal al l op l opl op l op op op erat erat erat eraterat rat ing ing ing inging g syst syst syst systsyst y em s em s em s em sem s m tubs tubs tubs tubs ubs ubs b to to to to t o o trantran tran tran tran ran n sf er sf er sf er sf er sf er sf er cod codcodcod cod cod e e or e or e or e oree tastas tas a ks. ks.ks. k 404

Oper

at

ing Syst

ems

versity

page 404 of

489

(c

hapter 7: “Oper

Types of curr

ent oper

ating systems

Embed

ded operating systems

•

usually real-time systems, of

ten hard real-time systems

• ve ry small f ootprint (of ten a f ew kBy tes) •

none or limited user

-interaction

G

90-95% of all processors are w

orking here!

Ar

tw

ork by Q

Of

ten ov

er 100 MPUs per car

(and some of them quite high per

formant) 401

Oper

at

ing Syst

ems

versity

page 401 of

489

(c

hapter 7: “Oper

e R. Zi mmer , T h e A ustr alian Nat ional Un iv ersity page 40 1 of y 489 (c hapt er 7: “O per ating Systems ” up to page 436 ) 9

Types of curr

ent oper

ating systems

Real-time operating systems need to provide...

G

the logical cor

rectness of the results as w

ell as

G

the cor

rectness of the time, when the results are deliv

ered

G

Predictability!

(not per

formance!)

G

All results are to be deliv

ered just-in-time – not too early

, not too late.

T

iming constraints are specifi

ed in man y dif ferent w ays ... ... of ten as a response to ‘e xternal’ ev ents G reactiv e systems Photo: NASA 398

Oper

at

ing Syst

ems

versity

page 398 of

489

(c

hapter 7: “Oper

9

Types of curr

ent oper

ating systems

Distributed operating systems

•

all CPUs car

ry

a small k

ernel operating system f

or communication ser

vices.

•

all other OS-ser

vices are distributed ov

er available CPUs

•

ser

vices may migrate

•

ser

vices can be multiplied in order to

•

guarantee availability (hot stand-by)

•

or to increase throughput (heavy duty ser

vers) 405

Oper

at

ing Syst

ems

versity

page 405 of

489

(c

hapter 7: “Oper

W

hat is an oper

ating system?

Is there a standard set of f

eatures f

or operating systems?

402

Oper

at

ing Syst

ems

versity

page 402 of

489

(c

hapter 7: “Oper

Types of curr

ent oper

ating systems

Embed

ded operating systems

•

usually real-time systems, of

ten hard real-time systems

• ve ry small f ootprint (of ten a f ew kBy tes) •

none or limited user

-interaction

G

90-95% of all processors are w

orking here!

Ar

tw

ork by Q

399

Oper

at

ing Syst

ems

versity

page 399 of

489

(c

hapter 7: “Oper

Types of curr

ent oper

ating systems

Real-time operating systems

• Fast conte xt switches? • Small siz e? • Quick response to e xternal inter rupts? • Multitasking? • ‘low lev el’ programming inter faces? •

Interprocess communication tools?

•

(3)

412

Oper

at

ing Syst

ems

versity

page 412 of

489

(c

hapter 7: “Oper

Typical featur

es of oper

ating systems

Memor

y manag

ement:

• Allocation / Deallocation • V ir tual memor y: logical vs. ph ysical ad

dresses, segments, paging, sw

apping, etc.

•

Memor

y protection (privileg

e lev

els, separate vir

tual memor y segments, ...) • Shared memor y

Synchronisation / Inter

-process communication

• semaphores, mute

xes, cond. variables, channels, mailbo

xes, MPI, etc. (chapter 4)

G

tightly coupled to scheduling / task switching!

Hardw

are abstraction

• Device driv ers • API • Protocols, fi le systems, netw orking, ev er y thing else... 409

Oper

at

ing Syst

ems

versity

page 409 of

489

(c

hapter 7: “Oper

W

hat is an oper

ating system?

Is there a standard set of f

eatures f

or operating systems?

G

no: the term

‘operating system’ cov ers 4 kB microk ernels, as w ell as > 1 GB installations of desktop g

eneral purpose operating systems.

Is there a minimal set of f

eatures?

G almost: memor y management, pr ocess management and inter -pr ocess communication/sync hr onisation

will be considered essential in most systems

Is there alw

ays an e

xplicit operating system?

406

Oper

at

ing Syst

ems

versity

page 406 of

489

(c

hapter 7: “Oper

W

hat is an oper

ating system?

Is there a standard set of f

eatures f

or operating systems?

G

no: the term

413

Oper

at

ing Syst

ems

versity

page 413 of

489

(c

hapter 7: “Oper

Typical structur

es of oper

ating systems

Monolithic

(or

‘the big mess...

’ ) • non-por table • hard to maintain • lacks reliability • all ser

vices are in the k

ernel (on the same privileg

e lev

el)

G

but: may reach high effi

cienc

y

e.g. most early UNIX systems, MS-DOS (80s), Windows (all non-NT

based v

ersions)

MacOS (until v

ersion 9), and man

y others... Hardw are

OS

Tasks

Monolithic APIs 410

Oper

at

ing Syst

ems

versity

page 410 of

489

(c

hapter 7: “Oper

W

hat is an oper

ating system?

Is there a standard set of f

eatures f

or operating systems?

G

no: the term

Is there a minimal set of f

eatures?

will be considered essential in most systems

Is there alw

ays an e

xplicit operating system?

G

no: some languag

es and dev

elopment systems operate with standalone runtime environments

407

Oper

at

ing Syst

ems

versity

page 407 of

489

(c

hapter 7: “Oper

W

hat is an oper

ating system?

Is there a standard set of f

eatures f

or operating systems?

G

no: the term

Is there a minimal set of f

eatures?

414

Oper

at

ing Syst

ems

versity

page 414 of

489

(c

hapter 7: “Oper

Typical structur

es of oper

ating systems

Monolithic & Modular

•

Modules can be platf

orm independent

•

Easier to maintain and to dev

elop

•

Reliability is increased

•

all ser

vices are still in the k

ernel (on the same privileg

e lev

el)

G

may reach high effi

cienc y e.g. cur rent Linux v ersions Hardw are

OS

Tasks

APIs _Modular

M1 M1 Mn … 411

Oper

at

ing Syst

ems

versity

page 411 of

489

(c

hapter 7: “Oper

Typical featur

es of oper

ating systems

Process manag

ement:

• Conte xt switch • Scheduling • Book k

eeping (creation, states, cleanup)

G

conte

xt switch:

G needs to... • ‘remov e’

one process from the CPU while preser

ving its state

•

choose another process (scheduling)

•

‘inser

t’

the new process into the CPU

, restoring the CPU state

Some CPUs hav

e hardw are suppor t f or conte xt switching, other wise: G use inter rupt mechanism 408

Oper

at

ing Syst

ems

versity

page 408 of

489

(c

hapter 7: “Oper

W

hat is an oper

ating system?

Is there a standard set of f

eatures f

or operating systems?

G

no: the term

Is there a minimal set of f

eatures?

(4)

421

Oper

at

ing Syst

ems

versity

page 421 of

489

(c

hapter 7: “Oper

Intr

oduction to pr

ocesses and thr

eads

1 CPU for all

_control-fl

ow

s

•

OS: emulate one CPU for ev

er y control-fl ow: Multi-tasking oper ating system G Suppor t f or memory protection essential. G

Process management (scheduling) required.

G

Shared memory access need to be coordinated.

stack code stack code stack code address space 1 shared memory stack code stack code CPU stack code address space n shared memory … 418

Oper

at

ing Syst

ems

versity

page 418 of

489

(c

hapter 7: “Oper

Typical structur

es of oper

ating systems

µK

ernels & client-ser

ver models

•

µk

ernel implements essential process,

memor y, and messag e handling • all ‘higher’ ser

vices are user lev

el ser

vers

• signifi

cantly easier to maintain

•

k

ernel ensures reliable messag

e passing

betw

een clients and ser

vers:

locally and through a netw

ork

•

highly modular and fl

e

xible

•

ser

vers can be redundant and easily replaced

•

possibly reduced effi

cienc

y through increased communications

e.g. J

ava engines,

distributed real-time operating systems, cur

rent distributed OSs research projects

µk

ernel, distributed systems

task 1 task n ser vice 1 µk ernel µk ernel ser vice m µk ernel Hardw are Netw ork 415

Oper

at

ing Syst

ems

versity

page 415 of

489

(c

hapter 7: “Oper

Typical structur

es of oper

ating systems

Monolithic & lay

ered

• easily

por

table

• signifi

•

crashing lay

ers do not necessarily stop the whole OS

•

cienc y through man y inter faces • rig

orous implementation of the stack

ed vir

tual machine

perspectiv

e on OSs

e.g. some cur

rent UNIX implementations (e.g. Solaris) to a cer

tain

de-gree, man

y research OSs (e.g.

‘THE system’ , Dijkstra ‘68) Hardw are

Tasks

Lay ered M0 M1 Mn

OS

APIs …

lay

ers

422

Oper

at

ing Syst

ems

versity

page 422 of

489

(c

hapter 7: “Oper

Intr

oduction to pr

ocesses and thr

eads

P

rocesses

Process ::= Ad dress space + Control fl ow(s) G K

ernel has full

knowledg e about all processes as w ell as their states , requirements and cur rently held resour ces . stack code stack code stack code address space 1 shared memory stack code stack code CPU stack code address space n shared memory …

process 1

process n

419

Oper

at

ing Syst

ems

versity

page 419 of

489

(c

hapter 7: “Oper

UNIX

UNIX f

eatures

• Hierarchical

fi

le-system (maintained via

‘mount ’ and ‘unmount ’) • Univ ersal fi le-inter face applied to fi

les, devices (I/O), as w

ell as IPC

•

Dynamic process creation via duplication

•

Choice of shells

•

Internal structure as w

ell as all APIs are based on

‘C

’

•

Relativ

ely high degree of por

tability G UNICS, UNIX, BSD , XENIX, System V , QNX

, IRIX, SunOS, Ultrix, Sinix,

Mac h, Plan 9, NeXTSTEP , AIX , HP -UX, Solaris, NetBSD , F reeBSD , Linux, OPEN-STEP , OpenBSD , Darwin, QNX/Neutrino, OS X, QNX R TOS, ... ... . 416

Oper

at

ing Syst

ems

versity

page 416 of

489

(c

hapter 7: “Oper

Typical structur

es of oper

ating systems

µK

ernels & vir

tual machines

•

µk

vices are dealt with outside the

k ernel ☞ no threat f or the k ernel stability • signifi

•

multiple OSs can be e

xecuted

at the same time

•

µk

ernel is highly hardw

are dependent

☞

only the µk

ernel needs to be por

ted.

•

cienc

y

through

increased communications e.g. wide spread concept: as early as the CP/M,

VM/370 (‘79)

or as recent as MacOS X (mach k

ernel + BSD unix), ... Hardw are µk ernel, vir tual machine µk ernel

Tasks

M0 M1 Mn

OS

APIs …

lay

ers

OS

Tasks

APIs M1 M1 Mn …

OS

Tasks

APIs 423

Oper

at

ing Syst

ems

versity

page 423 of

489

(c

hapter 7: “Oper

Intr

oduction to pr

ocesses and thr

eads

Threads

Threads (individual control- fl ows) can be handled: •

Inside the OS: G K ernel scheduling. •

Thread can easily be connected to external ev

ents (I/O). • Outside the OS: G User -lev el scheduling. •

Threads may need to g

o

through their

parent process to access I/O

. stack thread stack thread stack thread address space 1 shared memory stack thread stack thread CPU stack thread address space n shared memory …

process 1

process n

420

Oper

at

ing Syst

ems

versity

page 420 of

489

(c

hapter 7: “Oper

Intr

oduction to pr

ocesses and thr

eads

1 CPU per

_control-fl

ow

Specifi c confi gurations only , e.g.: • Distributed µcontrollers. • Ph ysical process

control systems: 1 cpu per task, connected via a bus-system.

G

Process management (scheduling) not required.

G

Shared memory access need to be coordinated.

CPU stack code CPU stack code CPU stack code address space 1 shared memory CPU stack code CPU stack code CPU stack code address space n shared memory … 417

Oper

at

ing Syst

ems

versity

page 417 of

489

(c

hapter 7: “Oper

Typical structur

es of oper

ating systems

µK

ernels & client-ser

ver models

•

µk

vices are user lev

el ser

vers

• signifi

•

k

ernel ensures reliable messag

e passing

betw

een clients and ser

vers

•

highly modular and fl

e

xible

•

ser

vers can be redundant and easily replaced

•

cienc

y

through

increased communications e.g. cur

rent research projects, L4, etc.

Hardw

are

µk

ernel, client ser

ver structure µk ernel ser vice m ser vice 1 task 1 task n

(5)

430

Oper

at

ing Syst

ems

versity

page 430 of

489

(c

hapter 7: “Oper

Pr

ocess states

CPU

creation y d a er h ct a b ready , suspended block

ed, suspended block

ed pre-emption or c ycle done termination n block or synchroniz e e xecuting admitted dispatch unblock suspend (sw ap-out) sw ap-in sw ap-out unblock suspend (sw ap-out) 427

Oper

at

ing Syst

ems

versity

page 427 of

489

(c

hapter 7: “Oper

Process states

• created

: the task is ready to run, but

not y et considered by an y dispatcher G w aiting f or admission • read y: ready to run G w aiting f or a free CPU • running

: holds a CPU and e

xecutes

•

bloc

ked

: not ready to run

G w aiting f or a resource blocked blocked ready running blocked dispatch timeout block release created admit terminated finish main memory 424

Oper

at

ing Syst

ems

versity

page 424 of

489

(c

hapter 7: “Oper

Intr

oduction to pr

ocesses and thr

eads

Symmetric

Multiprocessing

(SMP)

All CPUs share the same ph

ysical ad

dress space

(and access to resources).

G An y process / thread can be e xecuted on an y available CPU . stack thread stack thread stack thread a ddre ss s p a ce 1 sh a red memory stack thread stack thread stack thread a ddre ss s p a ce n sh a red memory …

1 process

process

n

CPU CPU CPU CPU … sh a red memory

physic

al

addre

ss s

pa

ce

431

Oper

at

ing Syst

ems

versity

page 431 of

489

(c

hapter 7: “Oper

Defi

nition of terms

T

ime sc

ales of scheduling

CPU

creation y d a er h ct a b ready , suspended block

ed, suspended block

ed pre-emption or c ycle done terminate. block or synchroniz e e xecuting admit dispatch suspend (sw ap-out) sw ap-in sw ap-out unblock suspend (sw ap-out) Long-term Short-term Medium-term 428

Oper

at

ing Syst

ems

versity

page 428 of

489

(c

hapter 7: “Oper

Process states

• created

: holds a CPU and e

xecutes

•

bloc

ked

: not ready to run

G w aiting f or a resource • suspended states: sw apped out of main memor y

(none time critical processes) G w

aiting f

or main memor

y

space (and other resources)

blocked blocked ready running blocked dispatch timeout block release created admit terminated finish blocked blocked blocked, susp. suspend (swap-out) ready, susp.

suspend (swap out)

release

reload (swap in)

main memory memory _secondary

425

Oper

at

ing Syst

ems

versity

page 425 of

489

(c

hapter 7: “Oper

Intr

oduction to pr

ocesses and thr

eads

P

rocesses

)

Threads

Also processes can share memor

y and the specifi

c

defi

nition of threads

is dif

ferent in dif

ferent operating systems and conte

xts:

G

Threads can be regarded as a group of processes, which share some resources (

G

process-hierarch

y).

G

Due to the ov

erlap in resources, the attributes attached to

threads are less than f

or ‘fi rst-class-citiz en-processes’ . G

Thread switching and inter

-thread communication can be

more effi

cient than switching on process lev

el.

G

Scheduling of threads depends on the actual thread implementations: • e.g.

user -le vel c ont rol-fl ow s, which the k

ernel has no knowledg

e about at all. • e.g. k e rnel-le vel c ont rol-fl ow

s, which are handled as processes with some restrictions.

432

Oper

at

ing Syst

ems

versity

page 432 of

489

(c

hapter 7: “Oper

P

erformance sc

heduling

R

equested resource times

time 0 5 101 52 02 5 303 54 04 5 (Ti, Ci) (4, 1) (12, 3) (16, 8) Tasks hav e an av er

age time between instantiations

of Ti and a constant computation time of Ci 429

Oper

at

ing Syst

ems

versity

page 429 of

489

(c

hapter 7: “Oper

Process states

• created

: holds a CPU and e

xecutes

•

bloc

ked

: not ready to run

G w aiting f or a resource • suspended states: sw apped out of main memor y

(none time critical processes) G w

aiting f

or main memor

y

space (and other resources) G dispatching and suspending can now be independent modules

blocked blocked ready running blocked dispatch timeout block release created admit terminated finish blocked blocked blocked, susp. suspend (swap-out) ready, susp.

suspend (swap out)

release

reload (swap in)

main memory memory _secondary

426

Oper

at

ing Syst

ems

versity

page 426 of

489

(c

hapter 7: “Oper

Intr

oduction to pr

ocesses and thr

eads

P

rocess C

ontrol Blocks

• Process Id • Process state : {created, ready , e xecuting, block

ed, suspended, bored …}

•

Sc

heduling attributes

:

Priorities, deadlines, consumed CPU-time, …

•

CPU state

: Sav

ed/restored inf

ormation while conte

xt

switches (incl. the program counter

, stack pointer

, …)

•

Memory attributes / pri

vileges

:

Memor

y base, limits, shared areas, …

•

Allocated resour

ces / pri

vileges

:

Open and requested devices and fi

les,

…

… PCBs (links thereof) are commonly enqueued at a cer

tain

state or condition (aw

aiting access or chang

e in state)

Process Id

Process state Saved registers

(complete CPU state)

Scheduling info Memory spaces /

privileges

Allocated resources /

privileges

(6)

436

Oper

at

ing Syst

ems

versity

page 436 of

489

(c

hapter 7: “Oper

Oper

ating Systems

• Oper

ating Systems

• Concept • Categ ories • Architectures

• Processes

• Defi nition • Relation to architectures • Scheduling

Summar

y

433

Oper

at

ing Syst

ems

versity

page 433 of

489

(c

hapter 7: “Oper

P

erformance sc

heduling

First come,

fi

rst ser

ved (FCFS)

time 0 5 101 52 02 5 303 54 04 5 (Ti, Ci) (4, 1) (12, 3) (16, 8) W aiting time : 0..11 , av erag e: 5.9 – Turnaround time : 3..12 , av erag e: 8.4 As tasks apply concur rent ly f

or resources, the actual sequence of ar

rival is non-deterministic.

G

hence ev

en a deterministic scheduling schema lik

e FCFS can lead to dif

ferent outcomes. 434

Oper

at

ing Syst

ems

versity

page 434 of

489

(c

hapter 7: “Oper

P

erformance sc

heduling

First come,

fi

rst ser

ved (FCFS)

time 0 5 101 52 02 5 303 54 04 5 (Ti, Ci) (4, 1) (12, 3) (16, 8) W aiting time : 0..11 , av erag e: 5.4 – Turnaround time : 3..12 , av erag e: 8.0 G In this e xample: the av erag e w

aiting times var

y betw een 5.4 and 5.9 the av erag

e turnaround times var

y betw een 8.0 and 8.4 G

Shortest possible maximal turnaround time!

435

Oper

at

ing Syst

ems

versity

page 435 of

489

(c

hapter 7: “Oper

P

erformance sc

heduling

R

ound R

obin (RR)

time 0 5 101 52 02 5 303 54 04 5 (Ti, Ci) (4, 1) (12, 3) (16, 8) W aiting time : 0..5 , av erag e: 1.2 – Turnaround time : 1..20 , av erag e: 5.8 G Optimiz ed f or swif t initial responses. G “Stretches out” long tasks. G Bound maximal w aiting time!