0% found this document useful (0 votes)
26 views75 pages

2019 Lecture 08-Concurrency (Part2)

Uploaded by

BCho
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
26 views75 pages

2019 Lecture 08-Concurrency (Part2)

Uploaded by

BCho
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 75

MONASH

INFORMATION
TECHNOLOGY

FIT2100 Semester 2 2019


Lecture 8:
Concurrency (Part 2)
(Reading: Stallings, Chapter 5 and
Chapter 6)
WEEK 9
Lecture 5: Learning Outcomes

❑ Upon the completion of this lecture, you should be able to:


▪ Discuss different concurrency mechanisms
▪ Describe how semaphores support mutual exclusion
▪ Understand the conditions of deadlock and starvation
▪ Explain three common approaches to dealing with
deadlock

2
What we have understood about the
problem of concurrency?
Edsger W. Dijkstra

❑ The problem of concurrent


processing was first
identified and solved by
Dijkstra.
❑ "Solution of a Problem in
Concurrent Programming
Control" (1965)

4
The Problem of Concurrency

❑ Concurrency is the fundamental concern in supporting


multiprogramming, multiprocessing, and distributed
processing.

❑ Race condition occurs when multiple processes or


threads read and write data items concurrently.

❑ Mutual exclusion is the condition where there is a set of


concurrent processes — only one of which is able to access
a given resource or perform a given function at at any time.

5
Concurrency: control mechanisms

❑ To avoid race conditions when two operations run in


parallel, critical sections of code have to be serialised
▪ Make one thread/process wait for another
▪ Create an imaginary ‘resource’ that only one process
may hold at a time
❑ Semaphores
❑ Mutexes
❑ Conditional variables
▪ Make a process/thread wait until a condition is
satisfied
▪ When another process/thread completes the critical
task, the waiting process/thread is unblocked

6
What are semaphores?
How can semaphores be used to control
concurrency problems?
The Concept of Flags

❑ Set a FLAG when a processing is using the shared


resource — others can check that flag and decide to
enter or wait in their critical section

❑ Binary value: FLAG is ON (used) or OFF (not-used)


— as a form of semaphore

Periodic testing for the availability of the flag is wastage of


resource; rather the process that returns the flag can send
a signal to the process that is waiting for that resource.

8
The Concept of Semaphores

❑ An integer variable used for signaling among


processes

❑ Only three operations are allowed on a semaphore:


 initialisation, increment or decrement
atomic
❑ Two types of semaphores: operations

 Binary semaphores which takes on only the


values 0 and 1
 Counting (general) semaphores takes integer
values

9
Semaphores: Operations

A variable that has an There is no way to


integer value upon inspect or manipulate
which only three semaphores other than
operations are defined. these three operations.

1. May be initialised to a non-negative integer value.


2. The semWait operation decrements the value.
 If the value becomes negative, then the process executing
the semWait is blocked. Otherwise, the process continues
execution.
3. The semSignal operation increments the value.
 If the resulting value is less than or equal to zero, then a
process blocked by a semWait operation, if any, is
unblocked.

10
Semaphores: Consequences

There is no way
to know which You do not
There is no way
process will know whether
to know before a
continue another process
process
immediately on a is waiting so the
decrements a
uniprocessor number of
semaphore
system when unblocked
whether it will two processes processes may
block or not are running be zero or one
concurrently

11
Counting Semaphores: Definition

12
Binary Semaphores: Definition

Continue
execution

13
WHAT IS A MUTEX?
Mutex: Mutual Exclusion Lock

❑ A related concept to binary semaphores


▪ Very similar, but with a specific use case.

❑ Mutex is a programming flag:


▪ set to 0 when it is locked
▪ set to 1 when it is unlocked
▪ Only one process (or thread) can hold the lock at a
time (others will block on attempting to get the lock)
❑ Difference from binary semaphores:
▪ The process/thread that locks the mutex must be
the one to unlock it

15
Mutual Exclusion: Using Semaphores

The semaphore s is
initialised to 1.
The first process that
executes a semWait()
will be able to enter the
critical section immediately,
setting the value of s to 0.

16
Mutual Exclusion: Shared Data Protected by a Semaphore

17
What is a deadlock?
(Another concurrency problem)
The Concept of Deadlock

❑ Permanent blocking of a set of processes that either


compete for system resources or communicate with
each other.

❑ A set of processes is deadlocked when each


process in the set is blocked awaiting an event that
can only be triggered by another blocked process in
the set.

No efficient solution in general.

19
Potential Deadlock

I need quad I need quad


C and D B and C

I need quad
I need quad A and B
D and A

20
Actual Deadlock

HALT until HALT until


D is free C is free

HALT until
B is free
HALT until
A is free
Deadlock: Joint Program Diagram

P will be blocked on the


request of Resource A

22
Deadlock: Joint Program Diagram

Q acquires B and then P


acquires A. As execution
proceeds Q will block on
A and P on B.

23
No Deadlock

P acquires one
resource, uses it and
releases it before
acquiring another
one.

24
What resources do processes
compete for?
Resource Categories

Reusable
• can be safely used by only one process
at a time and is not depleted by that use
• processors, I/O channels, main and
secondary memory, devices, and data
structures such as files, databases, and
semaphores

Consumable
• one that can be created (produced) and
destroyed (consumed)
• interrupts, signals, messages, and
information in I/O buffers

26
Reusable Resources: Two Processes Competing
D – Disk resource
T –Tape resource

27
Consumable Resources: Two Processes Communicating

❑ Consider a pair of processes, in which each process


attempts to receive a message from the other
process and then send a message to the other
process:

Deadlock occurs if the Receive is blocking (i.e., the receiving


process is blocked until the message is received).

28
Resource Allocation Graph

Within a resource
node, a dot is
shown for each
instance of that
resource

29
Resource Allocation Graph

Multiple
copies of the
same resource

30
Deadlock: Example
Circular chain of
processes and
resources that
results in deadlock

31
What are conditions for a deadlock
to occur?
Deadlock: The Four Conditions

These three can lead to the possibility of a deadlock while


with the fourth one indicates the existence of a deadlock

33
Deadlock: The Four Conditions Direct condition for
deadlock exists

First three conditions are indirect


(necessary) for a possibility of deadlock

34
What are three common approaches
to dealing with deadlock?
Dealing with Deadlock

❑ Prevention: adopt a policy that eliminates one of the


conditions.

❑ Avoidance: make the appropriate dynamic choices


based on the current state of resource allocation.

❑ Detection: attempt to detect the presence of


deadlock and take actions to recover when needed.

Three general strategies

36
Deadlock: Prevention, Avoidance, Detection

37
Deadlock: Prevention Strategy

❑ Design a system in such a way that the possibility of


deadlock is excluded

❑ Two main methods:


 Indirect — prevent the occurrence of one of the
three necessary conditions
 Direct — prevent the occurrence of a circular wait

38
Deadlock: Condition Prevention
Might not know all
Should not be the resources
disallowed needed in advance

Mutual
Hold and Wait
Exclusion

if access to a resource require that a process request


requires mutual exclusion all of its required resources at
then it must be supported one time and blocking the
by the OS process until all requests can
be granted simultaneously

39
Deadlock: Condition Prevention
Only practical when states
of resources can be easily
saved and restored later
❑ No Preemption
▪ If a process holding certain resources is denied a
further request, that process must release its
original resources and request them again
▪ OS may preempt the second process (which holds
the requested resources) and require it to release
its resources to the first process
Slow down processes and
denying resource access
❑ Circular Wait
▪ Define a linear ordering of resource types

40
Deadlock: Avoidance Strategy

❑ A decision is made dynamically whether the current


resource allocation request will, if granted, potentially
lead to a deadlock

❑ Avoidance allows some level of concurrency than


prevention

❑ Requires knowledge of future process resource


requests

41
Deadlock: Avoidance Approaches

Deadlock Avoidance

Process Initiation Resource Allocation


Denial Denial
• do not start a • do not grant an
process if its incremental resource
demands might request to a process
lead to deadlock if this allocation might
lead to deadlock

42
Avoidance Strategy: Resource Allocation Denial

❑ Referred to as the banker’s algorithm

❑ State of the system reflects the current allocation of


resources to processes

❑ Safe state — one in which there is


sequence of resource allocations to processes that
does not result in a deadlock

❑ Unsafe state — a state that is not safe

43
Avoidance Strategy: Determination of a Safe State

❑ The state of a system — four processes and three


resources
❑ Allocations have been made to the four processes

Need Matrix

Amount of Resources
existing available
resources after
Cij – Aij <= Vj for all j allocation

44
Avoidance Strategy: Determination of a Safe State

P2 runs to
completion
and releases
its resources
45
Avoidance Strategy: Determination of a Safe State

P1 makes the
request for
the remaining
resources
46
Avoidance Strategy: Determination of a Safe State

P3 runs to
completion

The state defined


originally is a safe state

47
Avoidance Strategy: Determination of an Unsafe State

SAFE-STATE
P2 →1-R1, 2-R3

UNSAFE-STATE
P1 →1-R1, 1-R3

48
Deadlock Avoidance: Implementation Logic

49
Deadlock Avoidance: Implementation Logic

Assume that process will


complete and will release
its resources

50
Deadlock Avoidance: Restrictions

❑ Maximum resource requirement for each process


must be stated in advance

❑ Processes under consideration must be independent


and with no synchronisation requirements

❑ There must be a fixed number of resources to


allocate

❑ No process may exit while holding resources

51
Deadlock: Prevention Strategy vs Detection Strategy

Deadlock prevention strategies are conservative


• limit access to resources by imposing restrictions
on processes

Deadlock detection strategies do the opposite


• resource requests are granted whenever
possible

52
Deadlock: Detection Algorithms

❑ A check for deadlock can be made as frequently as


each resource request or, less frequently, depending
on how likely it is for a deadlock to occur.

❑ Advantages (checking at each resource request):


▪ it leads to early detection
▪ the algorithm is relatively simple

❑ Disadvantage:
▪ frequent checks consume considerable processor
time

53
Deadlock: Detection Algorithms

1. Mark each process that has a row in the allocation matrix of


all zeros

2. Initialise a temporary vector W to equal the Available vector.

3. Find the index i such that process i is currently unmarked and


the i-th row of Q (request matrix) is less than or equal to W.
That is, Qik <= Wk for 1 <= k <= m. If no such row is found,
terminate the algorithm.

4. If such a row is found, mark process i and add the


corresponding row of the allocation matrix to W.
That is, set Wk = Wk + Aik for 1 <= k <= m. Return to step 3.

54
Deadlock Detection: Example

Available
vector

A deadlock exists if and only if there are unmarked


processes at the end of the algorithm

55
Deadlock Detection: Recovery Strategies

❑ Abort all deadlocked processes

❑ Back up each deadlocked process to some


previously defined checkpoint and restart all
processes

❑ Successively abort deadlocked processes until


deadlock no longer exists

❑ Successively preempt resources until deadlock no


longer exists

56
The Dining Philosophers problem

*Reading from Stallings, Chapter 6: 6.6


The Dining Philosophers Problem

❑ Each philosopher needs


2 forks to eat
❑ No two philosophers can
use the same fork at the
same time — satisfy
mutual exclusion
❑ No philosopher must
starve to death — avoid
deadlock and starvation

58
First Solution: Five Seated Philosophers

Deadlock occurs if all


philosophers want to
eat at the same time

59
Second Solution: Four Seated Philosophers

Maximum four seated


philosophers are
allowed

60
Summary of Lecture 8

❑ Semaphores are use for signaling among processes


and can be readily used to enforce a mutual exclusion
discipline.
❑ Deadlock is a situation of blocking a set of processes
that either compete for system resources or
communicate with each other.

Reading from Stallings, Chapter 5: 5.4,


Chapter 6: 6.1, 6.4, 6.6, 6.7

Next week: Mid semester break!

61
SUPPLEMENTARY SLIDES (non-examinable)
Semaphores: Strong vs. Weak

❑ A queue is used to hold processes waiting on a


semaphore.

❑ Strong semaphores:
▪ The process that has been blocked the longest
is released from the queue first (FIFO)

❑ Weak semaphores:
▪ The order in which processed are removed
from the queue is not specified

63
Strong Semaphore Mechanism: Example
A, B and C rely on
the result from D

One of the
D results is
available

64
What is the producer/consumer problem?
(The classical concurrency problem)

[non-examinable]
The Producer/Consumer Problem

General Situation The Problem

• One or more producers


are generating data and
placing these in a • Ensure that the
buffer producer cannot
• A single consumer is add data into a full
taking items out of the buffer
buffer one at a time • Consumer cannot
• Only one producer or a remove data from
consumer may access an empty buffer
the buffer at any one
time

66
The Producer/Consumer Problem: Infinite Buffer

n = (in-out) = number of
items in the buffer

67
Solving with Binary Semaphores: Incorrect Solution

n = number of items
in the buffer

There is, however, a


flaw in this program.
When the consumer
has exhausted the
buffer, it needs to
reset the delay
semaphore so that it
will be forced to wait
until the producer has
placed more items in
the buffer. This is the
purpose of the
statement: if n == 0
semWaitB (delay) .

68
Solving with Binary Semaphores: Incorrect Solution
A semaphore is
initialised to 1.

semWait operation
decrements the
semaphore value.

The number of items


in the buffer=n is
incremented.

The semaphore delay


is used to force the
consumer to semWait
if the buffer is empty.

semSignal operation
increments the
semaphore value.

69
Solving with Binary Semaphores: Incorrect Solution
In line 14, the consumer
fails to execute the
semWaitB operation. The
consumer exhausts the
buffer and set n to 0 (line
8), but the producer has
incremented n before the
consumer can test it in line
14. The result is a
semSignalB not matched by
a prior semWaitB . The
value of –1 for n in line 20
means that the consumer
has consumed an item from
the buffer that does not
exist. It would not do
simply to move the
conditional statement
inside the critical section of
the consumer because this
could lead to deadlock (e.g.,
after line 8 of the Table).

70
Solving with Binary Semaphores: Incorrect Solution

n = number of items in the buffer

Deadlock (the
producer will be
waiting for the buffer
— s to be released by
the consumer, but
consumer is blocked
on delay)

71
Solving with Binary Semaphores: Correct Solution

A fix for the problem is to introduce


an auxiliary variable that can be set
in the consumer’s critical section for
use later on. A careful trace of the
logic should convince you that
deadlock can no longer occur.

72
Solving with Counting Semaphores

Can we swap the order of semSignal(s) and


semSignal(n)?

How about swapping the order of


semWait(n) and semWait(s)?

73
The Producer/Consumer Problem: Finite Buffer

Circular storage

74
Solving with Counting Semaphores: Finite Buffer

producer must wait if there is no


empty space

consumer must wait if there are no


items in the buffer

75

You might also like