CSCI2413 Lecture 10 Operating Systems (OS) Inter-process communication phones off (please)

CSCI2413 Lecture 10

Operating Systems (OS)

Inter-process communication

phones off (please)

csci2413 - L11 2© De Montfort University, 2004/5

Lecture Outline Concurrency Resources Deadlocks

conditions for deadlock deadlock modeling

Deadlock strategies deadlock avoidance deadlock prevention deadlock detection & recovery the ostrich algorithm


Concurrency issues Communication among processes Sharing resources Synchronization of multiple processes Allocation of processor time

Difficulties with Concurrency Facilitate sharing of global resources Management of allocation of resources Programming errors difficult to locate


Shared Resources Physical resources

processor, memory, I/O devices, disks, etc.

Logical resources message queues, inodes, records in a d-base system, etc.

Different resources that can be acquiredseveral identical instances may be available

e.g. multiple printers or tape drives

the OS may choose any of them to satisfy a request

A resource is anything that can only be used by a single process at any instant of time


Deadlocks All operating systems have the ability to grant (temporary)

exclusive access to certain resources Often exclusive access is needed to more than 1 resource Suppose there are two processes, A and B, and two shared

resources, printer and tape A allocates the printer B allocates the tape

then A requests the tape and blocks until B releases it

and then B requests the printer and blocks until A releases it

both processes block forever - this is a deadlock


Bridge Crossing Example

Traffic only in one direction. Each section of a bridge can be viewed as a resource. If a deadlock occurs, it can be resolved if one car backs

up (preempt resources and rollback). Several cars may have to be backed up if a deadlock

occurs. Starvation is possible.


Resource Classification Pre-emptable resources

such a resource can be temporarily taken away from the process owning it with no ill effects

e.g. processor, memory

Non-pre-emptable resources once allocated to a process, removing such a resource (even

temporarily) could cause the computation to fail e.g. printers

Deadlocks occur with non-preemptable resources pre-emptable resources can be reallocated to avoid DL


Resource Allocation Sequence of events needed to use a resource is

request the resource use the resource release the resource

If the resource is not available when it’s requested, the requesting process is forced to wait in some systems, the process is automatically blocked in others, the allocation fails and returns an error

the process decides whether to wait some time and try again in most cases the process will sit in a tight loop requesting the resource

until it is available (as no other work can be done) in which case, the process is effectively blocked


Deadlock Definition Deadlock can be defined formally as

a set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause

In most cases, the event that each process is waiting for is the release of a resource currently held by another member of the set e.g. suppose there are three processes A, B & C one form of deadlock is

A waits for B, B waits for C, C waits for A another may be

A waits for B, B waits for A, C waits for B


Addressing Deadlock

Prevention: Design the system so that deadlock is impossible

Avoidance: Construct a model of system states, then choose a strategy that, when resources are assigned to processes, will not allow the system to go to a deadlock state

Detection & Recovery: Check for deadlock (periodically or sporadically), then recover

Manual intervention: Have the operator reboot the machine if it seems too slow


Conditions for Deadlock

A deadlock can only occur if the following four conditions hold simultaneously in a system mutual exclusion hold and wait no pre-emption

circular wait


“Mutual exclusion” conditiononly one process may use a resource

at a time

To prevent deadlock

do not require “mutual exclusion”

If this is a resource constraint, then mutual exclusion must hold at all times.(i.e. you can’t do anything about it!)


“Hold and Wait” condition

To prevent deadlock avoid hold and wait! Need to be sure a process does not hold one

resource while requesting another Approach 1: Force a process to request all

resources it needs at one time Approach 2: If a process needs to acquire a

new resource, it must first release all resources it holds, then reacquire all it needs


“No preemption” condition

To prevent deadlock allow preemption!

If a process holding certain resources is denied a further request, that process must release its original resources ( inefficiency in resource use)

If a process requests a resource that is held by another process, the OS may preempt the second process and require it to release its resources

( waste of CPU and other resources)

Can only be used in certain cases


“Circular wait” condition

To prevent deadlock

don’t go into a circular wait situation!


Deadlock!

P2 have resource A and need resource B to get its job done.

P1 have resource B and need resource A to get its job done.


Example Scenario Imagine there are three processes: A, B & C

and three resources: R, S, & T The resource allocations are as follows

process Arequest R

request S

release R

release S

process Brequest S

request T

release S

release T

process Crequest T

request R

release T

release R

If the operating system runs the processes to completion in order A, B then C all requests can be satisfied: no deadlock occurs

But, suppose there is pre-emptive multi-tasking


Unpredictable Results? A & C run in round-robin, then B

A B C

R S T

A requests RC requests TA requests SC requests RA releases RC releases TA releases SC releases RB requests SB requests TB releases SB releases T

A, B, & C all run in round-robin

A B C

R S T

A requests RB requests SC requests TA requests SB requests TC requests R

DEADLOCK!


Potential Deadlock Example As a potential deadlock example in UNIX

UNIX has a finite maximum size to its process table usually around 32,000 processes

if a fork fails (because the process table is full), then a reasonable strategy (used in practice by most UNIX programmers) is to wait a short time and try again

Suppose there are 100 slots free in process table ten processes run, each creates 12 (sub-)processes

each loops 12 times, forking and / or waiting the scheduler starts them all running in round-robin each forks 9 child processes - the process table is full

all ten processes wait forever to create the required children


Deadlock Prevention

Necessary conditions for deadlockMutual exclusionHold and waitNo preemption Circular waiting

Ensure that at least one of the necessary conditions is false at all times


Deadlock Avoidance Define a model of system states, then choose a

strategy that will guarantee that the system will not go to a deadlock state

Requires extra information, e.g., the maximum claim for each process

Resource manager tries to see the worst case that could happen. It does not grant an incremental resource request to a process if this allocation might lead to deadlock


Resource Allocation Denial

Referred to as the Banker’s algorithm

State of the system is the current allocation of resources to processes

Safe state is where there is at least one sequence that does not result in deadlock


The Banker’s Algorithm The banker’s algorithm

initialise an array with the number of each resource for each process keep an array of resources in use and

resources still needed whenever a resource request is made by a process

look for a process that can run to completion resources still needed are less than the available number

assume this process runs and frees it’s resources continue, until all processes are verified to be runnable if all processes can complete: safe, grant the request else: unsafe, deny the request

Unfortunately, this depends on future knowledge!and so is ‘impossible’ in practice


Deadlock Detection In the detection and recovery approach, the system does not

try to prevent deadlock occurring it simply detects when a deadlock has occurred and then

(automatically) takes some action to recover

The first step is, obviously, to detect the deadlock if there is a single instance of each resource type

a resource allocation graph can be constructed there are many published algorithms for finding cycles (deadlocks)

in such directed graphs if there are multiple instances of resource types

an algorithm very similar to the banker’s algorithm is used (but it does not require future knowledge to detect deadlock)


Deadlock Recovery Deadlock recovery methods include

recovery through pre-emption a deadlocked resource is taken away

again this causes big problems for resources such as printers may be possible to carefully choose the pre-emption to make this

work recovery through rollback

each resource allocation causes some form of checkpoint for the process to be saved by the operating system

similar to a process table entry for a pre-empted process on deadlock, processes ‘rewound’ to free required resources

may be very difficult & costly, if e.g. files have been written to recovery through process termination

crudest method is to kill one or more deadlocked processes with luck the deadlock with cease, if not kill more processes! but how can processes be killed without causing ‘damage’?


The Ostrich Algorithm Surprisingly, perhaps, ignoring the problem altogether is a

popular choice of algorithm! this is the ‘ostrich algorithm’: stick your head in the sand and pretend

that there is no problem at all Is this acceptable?

mathematicians say ‘no’ engineers say ‘calculate how often it’s likely to occur, and if that is

infrequent enough, then it’s tolerable’ computer scientists say ‘sure ... everyone expects a computer to hang

or crash occasionally’!

Most contemporary OS’s, including both UNIX and Windows NT, use the ostrich algorithm


The following slides are supplements, not covered in the lecture session

Also see chapter 6 pages 275 – 279, Stallings


Dining Philosophers Problem



5 Philosophers 5 forks Each philosopher needs two forks to eat with Devise a deadlock free strategy



1. Each Philosopher picks up L fork then R, eats and replaces forks – possible starvation.

2. Each philosopher picks up L fork. If R fork available takes it and eats; else puts L fork back ?

3. Buy 5 more forks !

4. Teach philosophers to eat spaghetti with 1 fork !

5. Allow only four philosophers at a time into the room.

6. Have at least one philosopher who is left handed in (2) above (R fork first).


UNIX Signals

UNIX uses signals for IPC synchronisation A UNIX signal is similar to a software interrupt

a process may send a signal to another processwhen a signal arrives, the receiving process stops

what it is doing and immediately services the signal A signal is sent by using the kill system call

kill(process_id, signal_number);


Signals …

The action taken when a signal is received by a process is specified by the signal system call it can (usually) be ignored it can terminate the process it can be ‘caught’ by a special signal handling

function


Signal ListSignal Name Cause Signal Name Cause

SIGHUPhangup on controlling terminal

or death of control process

SIGINTinterrupt from keyboard

(usually CTRL-C)

SIGQUITquit from keyboard(usually CTRL-\)

SIGILL illegal instruction

SIGABRT abort signal from debugger

SIGFPE floating point exception

SIGKILLkill signal

(cannot be caught or ignored)

SIGSEGV segmentation violation

SIGPIPEbroken pipe: write to pipe

with no readers

SIGALRMtimer signal from alarm

system call

SIGCHLDchild process stopped

or terminated

SIGTERMused to request that a process

terminates gracefully

SIGUSR1 user-defined signal 1

SIGUSR2 user-defined signal 2

SIGPWR power failure

SIGWINCH window resize signal


Signal ExamplesSIGKILL sent to a process to immediately kill it

this signal cannot be caught or ignored typically used by the system to stop processes at

shutdown or by root to kill runaway processes via the ‘kill’ command

SIGFPE floating point error

SIGSEGV illegal or invalid memory reference these can be caught by a program, to take

appropriate action


Signal ….SIGPIPE write on a pipe with no readers

can be caught to allow the ‘earlier’ processes in a pipe-line to exit when a ‘later’ process has exited abnormally

SIGINT/QUIT two levels of keyboard interruptSIGINT is ‘gentler’: interpreted as a request to

stop SIGQUIT is ‘harder’: an instruction to stop


Effect of a signal on a process

A program should be terminated, either normally exit executed, or abnormally - abort executed, depending on the signal received.

Other options :- ignore the signal; the arrival of the signal has

no effect. catch the signal; an exception routine called.


To ignore or catch a signal

A system call signal is used. e.g. to ignore signals :- #include <signal.h> signal(SIGINT, SIG_IGN); /* to ignore SIGINT */

signal(SIGINT, SIG_DFL); /* to change back to default */

CSCI2413 Lecture 10 Operating Systems (OS) Inter-process communication phones off (please)

Documents

Transcript of CSCI2413 Lecture 10 Operating Systems (OS) Inter-process communication phones off (please)