Adv OS Process Management

8/20/2019 Adv OS Process Management

1/80

AdvancedOperating Systems

1


2/80

Outline

Process Concept

Process Scheduling

Operations on ProcessesCooperating Processes

Threads

Interprocess Communication

2


3/80

Process Concept

An operating system executes a variety of

programs batch systems - obs

time-shared systems - user programs or tas!s ob and program used interchangeably

Process - a program in execution process execution proceeds in a se"uential fashion

A process contains program counter# stac! and data section

$


4/80

Process =? Program

%ore to a process than ust a program& Program is ust part of the process state

I run emacs on lectures'txt# you run it on home(or!'ava ) Same program#different processes

*ess to a process than a program& A program can invo!e more than one process cc starts up cpp# cc+# cc2# as# and ld

main ()

{

…;

}

A() {

…

}

main ()

{

…;

}

A() {

…

}

,eap

Stac!

A

main

Program Process


5/80


6/80

Process States

/e( - The process is being created'

0unning - Instructions are being executed'

1aiting - 1aiting for some event to occur'

0eady - 1aiting to be assigned to a

processor'

Terminated - Process has finished execution'


7/80

Process Control Block Contains information

associated (ith each process Process State - e'g' ne(#

ready# running etc'

Process /umber ) Process I3

Program Counter - address of

next instruction to be executed

CP4 registers - generalpurpose registers# stac! pointer

etc'

CP4 scheduling information -

process priority# pointer

%emory %anagement

information - base5limitinformation

Accounting information - time

limits# process number

I5O Status information - list

of I5O devices allocated

Process

Control

6loc!

7


8/80

Process SchedulingProcess (PCB) moves from queue to queue

When does it move? Where? A scheduling decision

8


9/80


10/80

Process Queues

Device

Queue

Ready

Queue

+<


11/80

Process

Control

6loc!

Enaling Concurrency andProtection! "ultiple#processes Only one process =PC6> active at a time Current state of process held in PC6&

?snapshot@ of the execution and protection environment

Process needs CP4# resources

ive out CP4 time to different processes=Scheduling>& Only one process ?running@ at a time ive more time to important processes

ive pieces of resources to different processes

=Protection>& Controlled access to non-CP4 resources

B'g' %emory %apping& ive each process their o(naddress space

++


12/80

Enaling Concurrency!Conte#t S$itchTas! that s(itches CP4 from one process to

another process the CP4 must save the PC6 state of the old process and

load the saved PC6 state of the ne( process'Context-s(itch time is overhead

System does no useful (or! (hile s(itching

Overhead sets minimum practical s(itching time can

become a bottlenec!

Time for context s(itch is dependent on

hard(are support = +- +


13/80

CP% S$itch &rom Process toProcess

Code executed in !ernel above is overhead Overhead sets minimum practical s(itching time

+$


14/80

Schedulers

*ong-term scheduler =or ob scheduler> - selects (hich processes should be brought into the ready

"ueue'

invo!ed very infre"uently =seconds# minutes> may be slo('

controls the degree of multiprogramming

Short term scheduler =or CP4 scheduler> - selects (hich process should execute next and allocates

CP4'

invo!ed very fre"uently =milliseconds> - must be very fast%edium Term Scheduler

s(aps out process temporarily

balances load for better throughput

+


15/80

"edium 'erm ('ime)sharing*Scheduler

+.


16/80

Process Pro+les

I5O bound process - spends more time in I5O# short CP4 bursts# CP4

underutiliDed'

CP4 bound process -

spends more time doing computations fe( very long CP4

bursts# I5O underutiliDed'

The right ob mix&

*ong term scheduler - admits obs to !eep load balancedbet(een I5O and CP4 bound processes

%edium term scheduler ) ensures the right mix =by

sometimes s(apping out obs and resuming them later>

+


17/80

Process Creation

Processes are created and deleteddynamically

Process (hich creates another process is

called a parent process the created processis called a child process'

0esult is a tree of processes e'g' 4/IE - processes have dependencies and form a

hierarchy'

0esources re"uired (hen creating process CP4 time# files# memory# I5O devices etc'

+7


18/80

%,-. Process /ierarchy

+8


19/80

Process Creation

0esource sharing Parent and children share all resources'

Children share subset of parentFs resources - prevents

many processes from overloading the system'

Parent and children share no resources'

Bxecution Parent and child execute concurrently'

Parent (aits until child has terminated'

Address Space Child process is duplicate of parent process'

Child process has a program loaded into it'

+;


20/80

%,-. Process Creation

Gor! system call creates ne( processes

execve system call is used after a for! to

replace the processes memory space (ith ane( program'

2<


21/80

Process 'ermination

Process executes last statement and as!sthe operating system to delete it =exit >'

Output data from child to parent =via (ait>'

ProcessF resources are deallocated by operating system'

Parent may terminate execution of childprocesses'

Child has exceeded allocated resources'

Tas! assigned to child is no longer re"uired'

Parent is exiting

OS does not allo( child to continue if parent terminates

Cascading termination

2+


22/80

Short Term Scheduling

The kernel runs the scheduler at least whena process switches from running to waiting

(blocks)a process is created or terminated.

an interrupt occurs (e.g., timer chip)

Non-preemptive system Scheduler runs when process blocks or is created, not on

hardware interruptsreemptive system !S makes scheduling decisions during interrupts, mostly

timer, but also system calls and other hardware deviceinterrupts

22

C it i f C i S h d li


23/80

Criteria for Comparing SchedulingAlgorithms

CPU Utilization The percentage of time that the"# is busy.Throughput The number of processes completingin a unit of time.Turnaround time

The length of time it takes torun a process from initiali$ation to termination,including all the waiting time.Waiting time The total amount of time that aprocess is in the ready %ueue.

Response time The time between when a processis ready to run and its ne&t '! re%uest.

2$


24/80


25/80

Process activity patterns

"# bound mp encoding Scientific applications (matri& multiplication) "ompile a program or document

'! bound

'nde& a file system rowse small web pages

alanced laying video oving windows aroundfast window updates

Scheduling algorithms reward '! bound andpenali$e "# bound /hy0

2.


26/80

Scheduling Policies

Simplifying 1ssumptions !ne process per user !ne thread per process (more on this topic ne&t week) rocesses are independent

*esearchers developed these algorithms in the 234s when

these assumptions were more realistic, and it is still an openproblem how to rela& these assumptions.

Scheduling 1lgorithms5 6"6S5 6irst "ome, 6irst Served

*ound *obin5 #se a time slice and preemption to alternate 7obs. S865 Shortest 8ob 6irst ultilevel 6eedback 9ueues5 *ound robin on priority %ueue. :ottery Scheduling5 8obs get tickets and scheduler randomly

picks winning ticket.

2


27/80

Scheduling Policies

FCFS: 6irst-"ome-6irst-Served (or 6'6!5 6irst-'n-6irst-!ut)

The scheduler e&ecutes 7obs to completion inarrival order.

'n early 6"6S schedulers, the 7ob did notrelin%uish the "# even when it was doing '!.

/e will assume a 6"6S scheduler that runs whenprocesses are blocked on '!, but that is non-

preemptive, i.e., the 7ob keeps the "# until itblocks (say on an '! device).

27


28/80

FCFS Scheduling Policy

'n a non-preemptive

system, the schedulermust wait for one ofthese events, but in apreemptive system thescheduler can interrupt a

running process.'f the processes arriveone time unit apart, whatis the average wait time

in these three cases0 1dvantages5

;isadvantages

28


29/80

Scheduling Policies

Round Robin5 very common base policy.

*un each process for its time slice (scheduling %uantum)1fter each time slice, move the running thread to the backof the %ueue.

Selecting a time slice5 Too large - waiting time su?ers, degenerates to 6"6S if

processes are never preempted. Too small - throughput su?ers because too much time is spent

conte&t switching. alance the two by selecting a time slice where conte&t

switching is roughly +< of the time slice.

1 typical time slice today is between +3-+33 milliseconds,with a conte&t switch time of 3.+ to + millisecond. a& :inu& time slice is ,33ms, /hy0

's round robin more fair than 6"6S0 1)=es )No

2;


30/80

Round Robin Examples

> 7obs, +33 seconds each, time slice + second, conte&t switchtime of 3, 7obs arrive at time 3,+,,,?

"ompletion Time /ait Time

8ob :ength 6"6S *ound *obin 6"6S *ound *obin

+ +33

+33

+33

? +33

> +33

1verage

$<


31/80

Round Robin Examples

> 7obs, of length >3, ?3, 3, 3, and +3 seconds each, timeslice + second, conte&t switch time of 3 seconds


8ob :ength 6"6S *ound *obin 6"6S *ound *obin

+ >3

?3

3

? 3

> +3

1verage

$+


32/80

SJF SRTF! Shortest Job First

Schedule the 7ob that has the least (e&pected) amount of work("# time) to do until its ne&t '! re%uest or termination. '! bound 7obs get priority over "# bound 7obs.

@&ample5 > 7obs, of length >3, ?3, 3, 3, and +3 seconds each,time slice + second, conte&t switch time of 3 seconds


8ob :ength 6"6S ** S86 6"6S ** S86

+ >3

?3

3

? 3

> +3

1verage $2


33/80

SJF SRTF! Shortest Job First

/orks for preemptive and non-preemptive

schedulers.

reemptive S86 is called S*T6 - shortestremaining time Arst.

1dvantages

;isadvantages

$$


34/80

"ultilevel Feedbac# $ueues

Using the Past to Predict the Future: ultilevelfeedback %ueues attempt to overcome theprediction problem in S86 by using the past '!and "# behavior to assign process priorities. 'f a process is '! bound in the past, it is also likely to

be '! bound in the future (programs turn out not to berandom.) To e&ploit this behavior, the scheduler can favor 7obs

(schedule them sooner) when they use very little "#time (absolutely or relatively), thus appro&imating S86.

This policy is adaptive because it relies on past behaviorand changes in behavior result in changes to schedulingdecisions. /e write a program in e.g., 8ava.

$

Approximating SJF! "ultilevel Feedbac#


35/80

Approximating SJF! "ultilevel Feedbac#$ueues

ultiple %ueues with different priorities.!S uses *ound *obin scheduling at each priority level,running the 7obs in the highest priority %ueue first.!nce those finish, !S runs 7obs out of the ne&t highestpriority %ueue, etc. ("an lead to starvation.)

*ound robin time slice increases e&ponentially at lowerpriorities.

$.

Approximating SJF! "ultilevel Feedbac#


36/80

Approximating SJF! "ultilevel Feedbac#$ueues

1d7ust priorities as follows (details can vary)5

+. 8ob starts in the highest priority %ueue. 'f 7ob4s time slices e&pire, drop its priority one level.. 'f 7ob4s time slices do not e&pire (the conte&t switch comes

from an '! re%uest instead), then increase its priority onelevel, up to the top priority level.

BBC 'n practice, "# bounds drop like a rock in priority and '!bound 7obs stay at high priority

$


37/80

%mproving Fairness

Since S86 is optimal, but unfair, any increase infairness by giving long 7obs a fraction of the "#when shorter 7obs are available will degradeaverage waiting time. ossible solutions5 Dive each %ueue a fraction of the "# time. This solution

is only fair if there is an even distribution of 7obs among%ueues. 1d7ust the priority of 7obs as they do not get serviced

(#ni& originally did this.) This ad hoc solution avoidsstarvation but average waiting time suffers when thesystem is overloaded because all the 7obs end up with a

high priority.

$7

h d li


38/80

&ottery Scheduling

Dive every 7ob some number of lottery tickets.!n each time slice, randomly pick a winning ticket.!n average, "# time is proportional to thenumber of tickets given to each 7ob.

1ssign tickets by giving the most to short running 7obs, and fewer to long running 7obs(appro&imating S86). To avoid starvation, every

7ob gets at least one ticket.;egrades gracefully as load changes. 1dding or

deleting a 7ob affects all 7obs proportionately,independent of the number of tickets a 7ob has'

$8

& S h d li


39/80

&ottery Scheduling

@&ample5 Short 7obs get E tickets, long 7obs get + tickets each.

F short 7obs

F long 7obs

< of "# each

short 7ob gets

< of "# each

long 7ob gets

++ E3< +3<

3

3

+3+

++3

$;

S f S h d li Al ith


40/80

Summary of Scheduling Algorithms

FCFS: Not fair, and average waiting time is poor.Round Robin5 6air, but average waiting time is poor.SJF5 Not fair, but average waiting time is minimi$edassuming we can accurately predict the length of the ne&t"# burst. Starvation is possible.Multilevel ueuing5 1n implementation (appro&imation) ofS86.!otter" Scheduling5 6airer with a low average waiting time,but less predictable.

⇒ !ur modeling assumed that conte&t switches took no time,which is unrealistic.

#e$t Time5 Threads5 multiple coordinating processes


41/80


42/80

Single and "ultithreadedProcesses

Threads encapsulate concurrency& ?Active@ component Address spaces encapsulate protection& ?Passive@ part Heeps buggy program from trashing the system

2


43/80

Single and "ultithreadedProcesses

Threads encapsulate concurrency& ?Active@ component Address spaces encapsulate protection& ?Passive@ part Heeps buggy program from trashing the system

$


44/80

Bene+ts

0esponsiveness

0esource Sharing

Bconomy

4tiliDation of %P Architectures


45/80

'hreads(Cont0*

In a multiple threaded tas!# (hile one server

thread is bloc!ed and (aiting# a second

thread in the same tas! can run'

Cooperation of multiple threads in the same ob confershigher throughput and improved performance'

Applications that re"uire sharing a common buffer =i'e'

producer-consumer> benefit from thread utiliDation'

Threads provide a mechanism that allo(sse"uential processes to ma!e bloc!ing

system calls (hile also achieving parallelism'

.


46/80

'hread StateState shared by all threads in process5addr

spaceContents of memory =global variables# heap>

I5O state =file system# net(or! connections# etc>

State ?private@ to each threadHept in TC6 ≡ Thread Control 6loc!

CP4 registers =including# program counter>

Bxecution stac! Parameters# Temporary variables

return PCs are !ept (hile called procedures are

executing


47/80

'hreads (cont0*

Thread context s(itch still re"uires a register

set s(itch# but no memory management

related (or!

Thread states - ready, blocked, running, terminated

Threads share CP4 and only one thread can

run at a time'/o protection among threads'

7


48/80

E#amples! "ultithreadedprogramsBmbedded systemsBlevators# Planes# %edical systems# 1rist(atchesSingle Program# concurrent operations

%ost modern OS !ernels

Internally concurrent because have to deal (ith

concurrent re"uests by multiple users

6ut no protection needed (ithin !ernel

3atabase Servers

Access to shared data by many concurrent users

Also bac!ground utility processing must be done

8


49/80

"ore E#amples! "ultithreadedprograms

/et(or! Servers Concurrent re"uests from net(or!

Again# single program# multiple concurrent operations

Gile server# 1eb server# and airline reservation systems

Parallel Programming =%ore than one physical CP4> Split program into multiple threads for parallelism

This is called %ultiprocessing

;


50/80

0eal operating systems have either One or many address spaces

One or many threads per address space

%ach# OS52# *inux1indo(s ;xJJJ

1in /T to EP# Solaris#,P-4E# OS E

Bmbedded systems=eo(or!s# Kx1or!s#

9avaOS#etc>

9avaOS# Pilot=PC>

Traditional 4/IE%S53OS# early

%acintosh

%any

One

L threads

Per AS&

%anyOne

L o

f a d d r

s p a c e s &

.<


51/80

'ypes o 'hreads

Hernel-supported threads =%ach and OS52>

4ser-level threads

,ybrid approach implements both user-level

and !ernel-supported threads =Solaris 2>'

.+


52/80

2ernel 'hreads

Supported by the Hernel /ative threads supported directly by the !ernel Bvery thread can run or bloc! independently One process may have several threads (aiting on different things

3o(nside of !ernel threads& a bit expensive /eed to ma!e a crossing into !ernel mode to schedule

Bxamples

1indo(s EP52


53/80

%ser 'hreads Supported above the !ernel# via a set of library calls

at the user level' Thread management done by user-level threads library

4ser program provides scheduler and thread pac!age

%ay have several user threads per !ernel thread 4ser threads may be scheduled non-premptively relative to

each other =only s(itch on yield=>> Advantages Cheap# Gast

Threads do not need to call OS and cause interrupts to !ernel

3isadv& If !ernel is single threaded# system call from any

thread can bloc! the entire tas!'

Bxample thread libraries& POSIE Pthreads# 1in$2 threads# 9ava threads

.$


54/80

"ultithreading "odels

%any-to-One

One-to-One

%any-to-%any

.


55/80

"any)to)One%any user-level threads mapped to single

!ernel thread

Bxamples&

Solaris reen Threads

/4 Portable Threads

..


56/80

One)to)One

Bach user-level thread maps to !ernel thread

Bxamples

1indo(s /T5EP52


57/80

"any)to)"any "odel Allo(s many user level

threads to be mapped tomany !ernel threads

Allo(s the operating

system to create a

sufficient number of!ernel threads

Solaris prior to version ;

1indo(s /T52


58/80

'hreads in Solaris 3

.8

'h d i S l i 3


59/80

'hreads in Solaris 3

0esource re"uirements of thread types Hernel Thread& small data structure and stac! thread

s(itching does not re"uire changing memory access

information - relatively fast'

*ight(eight Process& PC6 (ith register data# accounting

and memory information - s(itching bet(een *1P is

relatively slo('

4ser-level thread& only needs stac! and program

counter no !ernel involvement means fast s(itching'Hernel only sees the *1Ps that support user-level

threads'

.;

' l l " d l


60/80

'$o)level "odel

Similar to %&%# except that it allo(s a userthread to be bound to !ernel thread

Bxamples I0IE# ,P-4E# Tru 4/IE# Solaris 8 and earlier

<

'h di -


61/80

'hreading -ssues

Semantics of fork() and exec() systemcalls

Thread cancellation

Signal handlingThread pools

Thread specific data

Scheduler activations

+


62/80

C ti P


63/80

Cooperating Processes

Concurrent Processes can be Independent processes

cannot affect or be affected by the execution of anotherprocess'

Cooperating processes

can affect or be affected by the execution of another process'

Advantages of process cooperation& Information sharing

Computation speedup

%odularity

Convenience=e'g' editing# printing# compiling>

Concurrent execution re"uires process communication and process synchroniDation

$

- t C i ti


64/80

-nterprocess Communication(-PC*

Separate address space isolates processes ,igh Creation5%emory Overhead =0elatively> ,igh Context-S(itch Overhead

%echanism for processes to communicate and synchroniDe actions'

Kia shared memory - Accomplished by mapping addresses to common 30A% 0ead and 1rite through memory

Kia %essaging system - processes communicate (ithout resorting to

shared variables' send() and receive() messages

Can be used over the net(or!

%essaging system and shared memory not mutually exclusive

can be used simultaneously (ithin a single OS or a single process'

Proc + Proc 2 Proc $

Shared "emory


65/80

Shared "emoryCommunication

Prog +

Kirtual

Address

Space +

Prog 2

Kirtual

Address

Space 2

3ata 2

Stac! +

,eap +

Code +

Stac! 2

3ata +,eap 2

Code 2

Shared

Communication occurs by ?simply@ reading5(riting to shared

address page

0eally lo( overhead communication

Introduces complex synchroniDation problems

Code

3ata,eap

Stac!

Shared

Code

3ata,eap

Stac!

Shared

.

C ti P i


66/80

Cooperating Processes via"essage Passing IPC facility provides t(o operations'

send=message> - message siDe can be fixed or variable

receive=message>

If processes P and : (ish to communicate# they

need to& establish a communication lin! bet(een them

exchange messages via send5receive

Gixed vs' Kariable siDe message Gixed message siDe - straightfor(ard physical implementation#

programming tas! is difficult due to fragmentation

Kariable message siDe - simpler programming# more complex

physical implementation'

- l t ti Q ti


67/80

-mplementation Questions

,o( are lin!s establishedJ

Can a lin! be associated (ith more than 2

processesJ

,o( many lin!s can there be bet(een every pairof communicating processesJ

1hat is the capacity of a lin!J

Gixed or variable siDe messagesJ

4nidirectional or bidirectional lin!sJ

MM'

7

5i t C i ti


68/80

5irect Communication

Sender and 0eceiver processes must name

each other explicitly& send=P # message> - send a message to process P

receive=Q# message> - receive a message from process :

Properties of communication lin!& *in!s are established automatically'

A lin! is associated (ith exactly one pair of communicating

processes'

Bxactly one lin! bet(een each pair'

*in! may be unidirectional# usually bidirectional'

8

-ndirect Comm nication


69/80

-ndirect Communication

%essages are directed to and received from

mailboxes =also called ports> 4ni"ue I3 for every mailbox'

Processes can communicate only if they share a mailbox'

Send= A# message> 5N send message to mailbox A N5 Receive= A# message> 5N receive message from mailbox A N5

Properties of communication lin! *in! established only if processes share a common mailbox'

*in! can be associated (ith many processes'

Pair of processes may share several communication lin!s

*in!s may be unidirectional or bidirectional

;

-ndirect Communication


70/80

-ndirect Communicationusing mailo#es

7<

"ailo#es (cont *


71/80

"ailo#es (cont0*

Operations create a ne( mailbox

send5receive messages through mailbox

destroy a mailbox

Issue& %ailbox sharing P+# P2 and P$ share mailbox A'

P+ sends message# P2 and P$ receiveM (ho getsmessageJJ

Possible Solutions

disallo( lin!s bet(een more than 2 processes allo( only one process at a time to execute receive operation

allo( system to arbitrarily select receiver and then notifysender'

7+

"essage Bu6ering


72/80

"essage Bu6ering

*in! has some capacity - determine the

number of messages that can reside

temporarily in it'

:ueue of messages attached to lin! ero-capacity :ueues& < messages

sender (aits for receiver =synchroniDation is called

rendezvous>

6ounded capacity :ueues& Ginite length of n messages sender (aits if lin! is full

4nbounded capacity :ueues& Infinite "ueue length

sender never (aits

72

"essage Prolems


73/80

"essage Prolems )E#ception Conditions Process Termination

Problem& P=sender> terminates# :=receiver> bloc!s forever' Solutions&

System terminates :'

System notifies : that P has terminated'

: has an internal mechanism=timer> that determines ho( long to (aitfor a message from P'

Problem& P=sender> sends message# :=receiver> terminates'

In automatic buffering# P sends message until buffer is full or

forever' In no-buffering scheme# P bloc!s forever'

Solutions& System notifies P

System terminates P

P and : use ac!no(ledgement (ith timeout

7$

"essage Prolems


74/80

"essage Prolems )E#ception Conditions*ost %essages

OS guarantees retransmission

sender is responsible for detecting it using timeouts

sender gets an exception

Scrambled %essages %essage arrives from sender P to receiver :# but

information in message is corrupted due to noise in

communication channel'

Solution need error detection mechanism# e'g' C,BCHS4%

need error correction mechanism# e'g' retransmission

7

Producer Consumer Prolem


75/80

Producer)Consumer Prolem

Paradigm for cooperating processes

producer process produces information that is

consumed by a consumer process'

1e need buffer of items that can be filled byproducer and emptied by consumer'

4nbounded-buffer places no practical limit on the siDe of

the buffer' Consumer may (ait# producer never (aits'

6ounded-buffer assumes that there is a fixed buffer siDe'Consumer (aits for ne( item# producer (aits if buffer is full'

Producer and Consumer must synchroniDe'

7.

Producer Consumer Prolem


76/80

Producer)Consumer Prolem

7

Bounded Bu6er using -PC


77/80

Bounded Bu6er using -PC(messaging*

Producer repeat

M

produce an item in nextp

M

send=consumer # nextp>until false

Consumer repeat

receive= producer # nextc >

M consume item from nextc

M

until false

77

Bounded u6er Shared


78/80

Bounded)u6er ) Shared"emory SolutionShared data

var n

type item M'

var buffer & arrayQ


79/80

Bounded Bu6er ) Shared"emory SolutionProducer process - creates filled buffers

repeat

M

produce an item in nextp

M

while in+ mod n out do noop

buffer[in & nextp

in & in!" mod n

until false

7;


80/80

Documents

Adv OS Process Management