Operating Systems Lecture 15

1
Operating SystemsLecture 15

• Interprocess Communication

phones off (please)
2
Overview

• Interprocess synchronisation
• race conditions
• critical sections
• deadlocks
• The dining philosophers problem
• deadlock
• starvation

3
Interprocess Synchronisation
4
Basic Principles

• In the earlier discussion of processes, we have
  glossed over the significance and ramifications
  of the co-existence of processes within a system
• Several possible relationships between processes
• fully independent processes
• users working on separate applications within one
  system
• students compiling and running C programs in lab
  sessions
• independent but related processes
• users contributing to one application
• data entry clerks adding orders to sales control
  system
• concurrent programming applications
• applications constructed as a set of co-operating
  processes

5
Shared Resources

• Processes need to share resources
• physical resources
• processor, memory, I/O devices, disks, etc.
• logical resources
• data items such as message queues, data
  structures, etc.
• In general, resources can be classified as
• reusable
• not destroyed by being used
• processor, memory, etc.
• consumable
• transient data item or signal
• a message sent between one process and another

6
Interprocess Communication

• In a real system processes need to communicate
  with each other in order to co-operate
• There are several reasons for co-operating
• information sharing
• the processes are interested in the same
  information
• computational speedup
• a particular task may run faster if it can be
  broken down into multiple subtasks which run in
  parallel
• modularity
• may be carried out as a design requirement
• convenience
• an individual user may choose to work on many
  tasks at once

7
Synchronisation Problems

• As soon as we allow multiple processes to share
  resources and communicate, there are a number of
  potential process synchronisation problems that
  may occur
• race conditions
• two or more processes competing for a shared
  resource
• the result varies according to the order of
  process execution
• deadlocks
• a situation where two or more processes are each
  waiting for resources held by others
• starvation
• a process never gets access to a required resource

8
Recall

• Imagine an operating system has a print spooler
• when a process wants to print a file it enters
  the file name in a special spool directory
• the directory has numbered slots (spaces) for
  file names
• another process (the spooler demon) periodically
  checks to see if there are any files to be
  printed
• the operating system maintains two variables
• out holds the number of the next file to be
  printed
• in holds the number of the next free slot
• Now imagine two processes trying to print a file
  at the same time
• each needs to submit the file name to the spool
  queue

9
A Race
out 4
in 7
in 8
in 8
The operating systemis now in a
consistentstate, but B.doc willnever get
printed
process A
process A
in 7
in 8
B.doc
A.doc
This is called a race condition - theresult
will depend ona race between thetwo processes
process B
in 7
in 8
10
Critical Sections

• How do we avoid race conditions?
• the problem is caused by two processes having
  free (simultaneous) access to a shared resource
• the data item in in the example just seen
• We need to find some way to prohibit more than
  one process from accessing such a resource
• problems only occur during shared resource access
• The part of the process which accesses a shared
  resource is termed a critical section
• only one process must be allowed to be in a
  critical section at one time this is mutual
  exclusion

11
Example of Critical Sections
1. Process A starts to run
2. Neither process is in a critical section, so
A is allowed to enter its
3. Process B starts to run
4. Process B reaches itscritical section, but is
notallowed to enter - the process blocks
5. Process A is reactivated and leaves critical
section
6. Process B is reactivated and is now allowed
to enter its critical section
Process A
Process A
Process B
Process B
Process A
Process A
Process B
12
Flawed Attempt at Mutual Exclusion

• Lets try an obvious solution to achieve mutual
  exclusion, by setting a critical_region flag

while ( critical_region BUSY
) do_nothing critical_region BUSY ltdo
critical codegt critical_region FREE

• Unfortunately, this doesnt solve the problem!
• suppose process A is interrupted just after it
  has checked that the critical_region flag is
  FREE, but before it has run the next line to set
  it to BUSY
• process B then runs and checks the
  critical_region flag
• it finds it FREE, and it too enters the critical
  code region

13
Requirements for Solution

• The actual requirements needed for a correct and
  efficient solution to the mutual exclusion
  problem are far from obvious
• no two processes may be in their critical section
  at the same time
• no assumptions may be made about speeds or the
  number of processors
• no process running outside its critical section
  may block other processes
• no process should have to wait forever to enter
  its critical section

14
Deadlocks

• Even if the mutual exclusion problem is solved,
  there is another related problem deadlocks
• In many cases a process needs exclusive access to
  more than one 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

15
The Dining Philosophers

• A Problem ofInterprocess Communication

16
The Dining Philosophers

• Five philosophers are sat around a table to eat
• there are only five spoons
• two (left right) are needed to eat
• A philosopher thinks eats
• and nothing else!
• After thinking for a while,a philosopher tries
  to pickup left right spoon
• If successful, they eat for a whilethen put down
  the spoons
• How can this problem be solved?

17
A Proposed Solution
while ( TRUE ) think() take_spoon(i) take_s
poon((i 1) mod 5) eat() put_spoon(i) put_s
poon((i 1) mod 5)

• The functions perform the following actions
• think performs whatever action(s) thinking
  involves
• take_spoon waits until spoon is available, then
  takes it
• eat performs whatever action(s) eating involves
• put_spoon puts a spoon back on the table after
  use

18
Deadlock

• Unfortunately this first proposed solution is
  wrong!
• The solution suffers from deadlock
• Suppose all five philosophers happen to run at
  the same time
• each philosopher picks up the left-hand spoon
• each philosopher will then enter take_spoon to
  obtain the right-hand and will wait for it to
  become available
• all philosophers wait for each other
• there is no provision for giving up the wait

19
Starvation

• Lets try to improve the deadlock situation by
  not blocking if one spoon is not available
• check left is free if so, pick it up check
  right pick up
• if not, release any spoons being held and try
  again
• Consider the following situation
• each philosopher in turn picks up left hand spoon
• the right hand spoon is not available
• each philosopher puts down the left hand spoon
• now loop around again!
• This situation is called starvation
• processes continue to run, but one() never
  progress

20
Another Proposal

• The starvation problem seems to occur if all
  philosophers keep picking up the left-hand spoon
  and releasing it in perfect synchronisation
• so lets solve the problem by adding a random
  amount of time after failing to acquire the
  right-hand spoon
• the chances of the simultaneous locking
  continuing for any length of time are minuscule
• this must work eventually
• This solution will work in practice
• however, it is not completely satisfactory
• particularly in time-critical or safety-critical
  applications

21
Summary

• Interprocess synchronisation
• race conditions
• critical sections
• deadlocks
• The dining philosophers problem
• deadlock
• starvation