CMPT 300
Introduction to Operating
Systems
Mutual Exclusion
© Janice Regan, CMPT 300, May 2007
0
Implementation
 Now we have the basic ideas we need
 How do we actually implement mutual exclusion?
 There are several approaches








Interrupt disabling
Lock variables
Strict alternation
Special instructions
Peterson’s solution
Message passing
Semaphores and Mutexes
Monitors
© Janice Regan, CMPT 300, 2007-2016
1
General form, mutual exclusion
 No matter how we implement mutual exclusion,
conceptually the following happens in each process
using the resource protected my mutual exclusion


NonCriticalRegion()
StartCriticalRegion()
CriticalRegion()
EndCriticalRegion()
NonCritical Region()


© Janice Regan, CMPT 300, 2007-2016
2
General form, mutual exclusion
 We must now think about how the implement the
StartCriticalRegion() and EndCriticalRegion()
operations

 Must consider how multiple processes running these
at the same time interact


What happens to a request to StartCriticalRegion() if another
process’s critical region is executing when the request occurs
(drop, queue …)?

How do we assure that a process cannot access a resource
allocated to another process?
© Janice Regan, CMPT 300, 2007-2016
3
Interrupts: hardware based solution
 Interrupts may be generated by hardware
devices and by software instructions (for many
instruction sets)
 Some interrupts can be disabled, others cannot

Most interrupts may be blocked (disabled), these are
called maskable interrupts.
 Usually there are few interrupts that cannot be
disabled (non maskable interrupts NMI) these include

software/hardware commands like reset that need to be
available regardless of whether interrupts are masked.
© Janice Regan, CMPT 300, 2007-2016
4
Nested interrupts
 What happens when an interrupt occurs while
the system is processing another interrupt.
 The interrupt generates a signal which is

acknowledged immediately by the hardware
supporting the interrupt queue (PIC), and placed in
the interrupt queue
 Ignored while the CPU is busy. In this case the
device requesting the interrupt may retransmit the
request periodically until it receives an
acknowledgment
 Ignore while the CPU is busy, lose all such interrupts
© Janice Regan, CMPT 300, 2007-2016
5
Common question?
 If interrupts are disabled within a critical section
how does the CPU know when I/O is done? It
will not get the interrupt from the I/O device.
 No, it will get the interrupt (for most systems).
To explain why we need to understand two facts

When you disable interrupts you can disable a
particular interrupt or set of interrupts necessary to
protect your shared resource
 Interrupts can also be generated in software
© Janice Regan, CMPT 300, 2007-2016
6
Disable Interrupt/s
 When you disable/enable interrupts
 You can disable/enable all possible interrupts in the
system


You may need to re-enable particular interrupts that you
need to complete your critical region
You can disable/enable a particular interrupt or set of
interrupts necessary to protect your shared resource
 When you disable all interrupts you prevent the
present process from being swapped out of the
CPU by the scheduler (no timer interrupts to end
its time slice)
© Janice Regan, CMPT 300, 2007-2016
7
Disabling Interrupts: step by step
 Have each process entering a critical region take each
of the following steps

Run StartCriticalRegion().




Run CriticalRegion(), safely reading/writing shared memory.


Begin by disabling all interrupts
Enable hardware interrupts needed for I/O to be completed within
the critical region
Assure that during I/O waits the scheduler is not called
You can be sure that no other process will change the shared
memory while the present process works with it because there is
no way to switch to another process.
Run EndCriticalRegion()

Immediately before completion re-enable interrupts
© Janice Regan, CMPT 300, 2007-2016
8
Problems with disabling interrupts
 Must be very efficient in placing the minimum amount of
work inside the critical region. Minimize increase in
turnaround time

Since each process must wait for the read or write of the
protected shared memory the CPU is idle during those waits
reducing the utilization of the CPU while the I/O hardware is
busy.
 Works on a single processor, not a multiprocessor
system (multicore?).

Interrupts are disabled on only one processor, the other
processors can still access the shared information, mutual
exclusion is not assured, so order of process execution may
matter
© Janice Regan, CMPT 300, 2007-2016
9
Other possible drawbacks
 User processes StartCriticalRegion() and
EndCriticalRegion() must have direct access to
instructions to disable interrupts. Such
instructions may be privileged mode
instructions.

In a multiprocessing system with competing
processes this is not desirable, one process could
disable interrupts and run to completion making other
processes wait.
 In a multiprocessing system where processes are
cooperating to accomplish a single goal. (Like
software to run your cell phone) this can be a very
useful and practical solution
© Janice Regan, CMPT 300, 2007-2016
10
Locking variables:
A software based solution?
 Use a shared variable to control access to
shared memory resources (do not disable
interrupts)
 Define a shared variable, say lock1

If the value of the variable lock1 is 1 the process
must wait to access the resource
 If the value of the variable lock1 is 0 the process sets
it to 1 then accesses the resource
 Upon completion the process sets lock1 to 0
© Janice Regan, CMPT 300, 2007-2016
11
Locking Variable
int lock1 = 0
// =1 is locked
void main() {
 (lock1 == 1) { }
while
lock1 = 1;
CriticalSection();
lock1 = 0;
NonCriticalSection();
}
© Janice Regan, CMPT 300, 2007-2016
12
Example of problem: locking
 Process 1 is interrupted after the while
statement
 Process 2 runs and encounters a critical
section, sets lock to 1 and starts processing the
critical section
 Process 2 enters a wait state (say a wait for
input) and process 1 is again allowed to run
 Process 1 sets lock to 1 (no change) then
begins its critical section. Two critical sections
are now being executed at the same time!!
Mutual exclusion is violated
© Janice Regan, CMPT 300, 2007-2016
13
Problems
 The lock variable needs mutual exclusion
too!
 Exactly the same problem as we saw with
the print queue example. The lock variable
can be changed by another process after
it is set and before it is used by the
present process.
© Janice Regan, CMPT 300, 2007-2016
14
Fixing the lock
 The problem is caused by a need for mutual
exclusion on the lock variable
 How can we remove that problem?

Use multiple lock variables, one for each process
 Enforce strict alternation between two processes
 Use special atomic instruction for access to lock
variables
© Janice Regan, CMPT 300, 2007-2016
15
Special instructions


Some CPUs have special instructions that can help with protecting
lock variables
A single non-divisible instruction is supplied to do the following.
Since the instruction is atomic (cannot be interrupted) there is no
problem caused by interrupts in the test and set sequence
bool testSet( int i) {
if( i == 0 ) {
i = 1;
return true;
}
else {
return false;
}
}
© Janice Regan, CMPT 300, 2007-2016
16
Test and set instruction: Use
 To use the testSet instruction
while(true) {
while(!testSet(lock)) { }
CriticalSection();
lock = 0;
NonCriticalSection();
}
 Uses busy waiting, any lock using busy waiting
(spin waiting) is known as a “spin lock”
© Janice Regan, CMPT 300, 2007-2016
17
Problems: Test and set instruction
 Use of the testSet() instruction can cause
deadlock due to priority inversion

Consider a low priority process Plow and a high
priority process Phigh
 A priority inversion occurs when Phigh is blocked
(forced to wait for Plow) by Plow



Plow is running and has entered a critical region for a
particular resource
Phigh becomes ready to run preempts Plow and begins to
run
Phigh tries to enter a critical region for the resource locked
by Plow and is blocked until Plow finishes with the
protected shared resource (If the Plow cannot run because
it is lower priority this causes a deadlock)
© Janice Regan, CMPT 300, 2007-2016
18
Problems: Test and set instruction
 Requires the inefficiency of busy waiting
 Starvation is possible





Consider a system where 3 processes are sharing a resource
When process 1 exits from its critical sect ion both process 2
and process 3 are waiting for the resource (they both want to
enter their own critical sections)
The next process that is given access to the resource is chosen
arbitrarily, say process 2 is chosen
Before process 2 finishes with the resource processes 5.and 6
also reach a point where they want to enter a critical region to
use the same resource
Processes can keep arriving and being chosen to run their
critical regions before process 2, it is possible that process 2
will never get its turn.
© Janice Regan, CMPT 300, 2007-2016
19