Concurrency and

Parallelism

COMP7940 - Cloud Computing

slides adopted from the textbook

Contents
1. Concurrency.
2. Concurrency and cloud computing.
3. Control flow and data flow computational models.
4. BSP and Multicore-BSP computation models.
5. Petri net models of concurrency.
6. Process states, events, process and thread groups.
7. Communication protocols and process coordination.
8. Logical clocks.
9. Runs and cuts.
10. Critical sections, locks, deadlocks, and atomic actions.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 2

 1. Concurrency
◼ Leslie Lamport: “What I call concurrency has gone by many names,
including parallel computing, concurrent programming, and
multiprogramming. I regard distributed computing to be part of the
more general topic of concurrency.’’
◼ Is there a distinction between concurrency and parallel processing?
 Concurrency describes the necessity that multiple activities take place
at the same time, while parallel processing implies a solution; there are
several processors capable of carrying out the computations required by
these activities at the same time, i.e., concurrently.
 Concurrency emphasizes cooperation and interference among
activities, while parallel processing aims to shorten the completion time
of the set of activities, and it is hindered by cooperation and activity
interference.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 3

Concurrency, coordination, and communication
◼ Execution of multiple activities in parallel can proceed either quasi-
independently, or tightly coordinated with an explicit communication
pattern. In either case, some form of communication is necessary to
coordinate concurrent activities.
◼ Coordination complicates the description of a complex activity as it
has to characterize the work done by individual entities working in
concert, as well as the interactions among them.
◼ Coordination is ubiquitous in our daily life; the lack of coordination
has negative implications, e.g., deadlocks!
◼ Communication
 Affects the overall efficiency of concurrent activities and could
significantly increase the completion time of a complex task and even
hinder the completion of the task.
 Requires prior agreement on the communication discipline described by
a communication protocol.

Cloud Computing Second Edition -

Dan C. Marinescu Chapter 3. 4
 A B

J J

K K

A B

Consequences of the lack of coordination → the absence of traffic

lights or signs in intersections causes a traffic jam. Blocking the
intersections, a shared resource for North-South and East-West traffic
flows, contributes to the deadlocks
Cloud Computing Second Edition -
Dan C. Marinescu Chapter 3. 5
Synchronization of concurrent activities
◼ Synchronization is a defining aspect of concurrency.
◼ Diner philosophers problem:
 Five philosophers sitting at a table alternately think and eat.
 A philosopher needs the two chopsticks placed left and right of her plate
to eat.
 After finishing eating a philosopher must place the chopsticks back on
the table to give a chance to left and right neighbors to eat.
◼ The problem is nontrivial, the naive solution when each philosopher
picks up the chopstick to the left, and waits for the one to the right to
become available, or vice versa, fails because it allows the system
to reach a deadlock state, in which no progress is possible.

Cloud Computing Second Edition -

Dan C. Marinescu Chapter 3. 6
 chopstick
Ph

r
ilo

he
so

op
ph

s
lo
e

i
r

Ph
1

chopstick 5 2 chopstick
Philo

r
sophe
s op he

Philo
4 3
r

ch
op
k
ic

st
st

ic
op

k
ch

Philosopher

Dijkstra's solution to the dining philosophers requires numbering of

chopsticks and two additional rules to avoid deadlock .
Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 7
Dijkstra’s solution to dining philosophers problem
◼ Dijkstra proposed the following solution formulated in terms of
general resources:
 Assign a partial order to the resources
 Impose the rule that resources must be requested in order.
 Impose the rule that no two resources unrelated by order will ever be
used by a single unit of work at the same time.
◼ Resources are the chopsticks, numbered 1 through 5 and each unit
of work, i.e., philosopher, will always pick up the lower-numbered
chopstick first, and then the higher-numbered one next to her.
◼ This solution avoids starvation. If four of the five philosophers pick
up their lower-numbered chopstick at the same time, only the
highest-numbered chopstick will be left on the table. Therefore, the
fifth philosopher will not be able to pick up a chopstick. Only one
philosopher will have access to that highest-numbered chopstick, so
she will be able to eat using two chopsticks.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 8

 chopstick
Ph

r
ilo

he
so

op
ph

s
lo
e

i
r

Ph
1

chopstick 5 2 chopstick
Philo

r
sophe
s op he

Philo
4 3
r

ch
op
k
ic

st
st

ic
op

k
ch

Philosopher

Dijkstra's solution to the dining philosophers requires numbering of

chopsticks and two additional rules to avoid deadlock .
Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 9
 2. Concurrency and cloud computing
◼ Practical motivations for concurrent execution of computer applications
is to overcome the physical limitations of one computer system by
distributing the workload to several systems and get results faster.
◼ Concurrency is at the heart of cloud computing, the large workloads
generated by many applications run concurrently on multiple instances
taking advantage of resources only available on computer clouds.
◼ Concurrent entities must communicate with one another to accomplish
the common task.
◼ To exploit concurrency a computation is decomposed into tasks and
the tasks are assigned to physical processing elements running
concurrently.
◼ Example: conversion of 50 x106 images from one format to another.
This is an embarrassingly parallel application, five threads running on
five cores, each processing 106 images, do not communicate with one
another and achieve a speedup of almost 50.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 10

 Speedup
t0 t1 t2 t3 t4 t5 t6 t7 t8

time

Sequential execution

Parallel execution

Sequential versus parallel execution of an application. The sequential execution

starts at time t0 goes through a brief initialization phase till time t1, then starts the
actual image processing. When all images have been processes it enters a brief
termination phase at time t7, and finishes at time t8.
The concurrent/parallel execution has its own brief initialization and termination
phases, the actual image processing starts at time t1 and ends at time t2. The results
are available at time t3 <<t8.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 11

Concurrency and communication
◼ Two sides of the concurrency:
 Algorithmic or logical concurrency.
 Physical concurrency discovered and exploited by the software and the
hardware of the computing substrate; e.g.,, a compiler can unroll loops
and optimize sequential program execution, a processor core may
execute multiple program instructions concurrently.
◼ Barrier synchronization → sometimes, a computation consists of
multiple stages when concurrently running threads cannot continue
to the next stage until all of them have finished the current one. This
leads to inefficiencies.
◼ Communication speed is considerably slower than computation
speed. During the time to send or receive a few bytes a processor
could execute billions of instructions.
◼ Intensive communication can slow down considerably the group of
concurrent threads of an application.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 12

Barrier synchronization

T1 T 2 T3 T4 T 5 T 6 T 7
t0

Stage 1

t1

Stage 2

t2

time

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 13

Coarse-grained and fined-grained parallelism
◼ Coarse grained parallelism →large blocks of code are executed
before concurrent threads communicate
◼ Fine-grained parallelism → short bursts of computations alternate
with relatively long periods when a thread waits for messages from
other threads

Thread i

Thread j

Thread k

solid black bars: running threads

white bars: blocked threads waiting for message
Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 14
Data parallelism versus task parallelism
◼ Data parallelism → input data of an application is distributed to
multiple processors/cores running concurrently.
 SIMD – Same Program Multiple Data; example, converting a large number of
images in from one format to another – given 109 images batches of 106 images
can be processed concurrently by 103 processors for a speedup of 1,000.
 Embarrassingly parallel applications
 Map Reduce

◼ Task parallelism → tasks are distributed to multiple processors;

example – data from different sensors providing images, sounds,
data can be processed concurrently by different programs each one
tasks to identify specific anomalies.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 15

3. Control flow and data-flow computation models
◼ Control flow → implemented by the
ubiquitous von Neumann model for
sequential execution.
 At each step the algorithm specifies the step
to be executed next.
 Concurrency can only be exploited through
the development of a parallel algorithm
reflecting the decomposition of a
computational task into processes/threads
that can run concurrently while exchanging
messages to coordinate their progress.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 16

3. Control flow and data-flow computation models
◼ Data flow models → based on an implicit communication model,
where a thread starts execution as soon as its input data become
available.
 The model is able to effortlessly extract the maximum amount of
parallelism from any computation.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 17

4. Bulk Synchronous Parallel model (BSP)
◼ Bridging hardware-software model by Leslie Valiant
 Unambiguous computational model.
 Avoids logarithmic losses of efficiency in parallel processing.
 Including parameters quantifying the physical constraints of the
computing substrate.
 Includes a nonlocal primitive, barrier synchronization.
◼ Frees a programmer from managing memory, communication,
and low-level synchronization, provided that the programs are
written with sufficient parallel slackness.
◼ Parallel slackness → hiding communication latency by providing
each processor with a large pool of ready-to-run tasks while other
tasks are waiting for either a message or for completion of
another operation.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 18

 Model components and computation steps
◼ Model components:
 Processing elements and memory.
 A router involved in message exchanges between pairs of components;
◼ g - throughput of the router and s - startup cost.

 Synchronization mechanisms acting every L units of time.

◼ Computation steps:
 At the beginning of a superstep each component is assigned a task
 At the end of the time allotted to the superstep, after L units of time since
its start, a global check determines if the superset has been completed.
◼ If so, the next superstep is initiated

◼ Else, another period of L units of time is allocated allowing the superset

to continue its execution.
◼ Local operations do not automatically slow down other processors. A
processor can proceed without waiting for completion of processes in
the router or in other components when synchronization is switched off.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 19

5. Petri Nets (PNs)

◼ PNs → bipartite graphs; tokens that flow through the graph.

◼ Used to model the dynamic rather than static behavior of systems,
e.g., detect synchronization anomalies.
◼ Bipartite graph → graphs with two classes of nodes; arcs always
connect a node in one class with one or more nodes in the other class.
◼ PNs are also called Place-Transition (P/T) Nets. The two classes of
nodes are: places and transitions. Arcs connect one place with one or
more transitions or a transition with one or more places.
◼ Firing of a transition removes tokens from its input places and adds
them to its output places.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 20

Modeling concurrency with Petri Nets

◼ PNs can model control flow as well as data flow systems.

◼ Petri Nets can model different activities in a system.
 A transition may model the occurrence of an event, the execution of a
computational task, the transmission of a packet, a logic statement.
 The input places of a transition model the pre-conditions of an event,
the input data for the computational task, the presence of data in an
input buffer, the pre-conditions of a logic statement.
 The output places of a transition model the post-conditions associated
with an event, the results of the computational task, the presence of
data in an output buffer, or the conclusions of a logic statement.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 21

 p1 p2 p1 p2 p1 p2

2 1 2 1 2 1
t1 t1 t1
3 3 3

p3 p3 p3

(a) (b) (c)

Petri Nets firing rules. (a) An unmarked net with one transition t1 with two input
places, p1 and p2 and one output place, p3. (b) The marked net, the net with
places populated by tokens; the net before firing the enabled transition t1.
(c) The marked net after firing transition t1 two tokens from place p1 and one
from place p2 are removed and transported to place p3

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 22

 p4

t3

p1 p1 p2 p1 p2 p3

t1 t2 t1 t2 t3 t1 t2

(a) (b) (c)

Petri Nets modeling.

◼ (a) Choice; only one of the transitions, t1 or t2 , may fire.
◼ (b) Symmetric confusion; transitions t1 and t3 are concurrent and, at the same
time, they are in conflict with t2. If t2 fires, then t1 and/or t3 are disabled.
◼ (c) Asymmetric confusion; transition t1 is concurrent with t3 and it is in conflict
with t2 if t3 fires before t1.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 23

Examples of PN models
(a) A state machine; there is the choice of firing t1, or t2; only one
transition fires at any given time, concurrency is not possible.
(b) A marked graph can model concurrency but not choice; transitions t2
and t3 are concurrent, there is no causal relationship between them.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 24

Examples of PN models
c) An extended net used to model priorities; the arc from place p2 to t1 is
an inhibitor arc. The process modeled by transition t1 is activated only
after the process modeled by transition t2 is activated.
d) Modeling exclusion; transitions t1and t2 model writing and, respectively,
reading with n processes to a shared memory. At any given time only
one process may write, but any subset of the n processes may read at the
same time, provided that no process writes.

inhibitor arc: the arc reverse

the logic, enable p2 if it is
empty.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 25

A barber shop example

1 1

1 1

Cloud Computing Second Edition -

Dan C. Marinescu Chapter 3. 26
The barber shop with two barbers

1
1
1 1

1
1
1

1
1
1

1
1 1

Cloud Computing Second Edition -

Dan C. Marinescu Chapter 3. 27
Petri Nets Reference
◼ https://en.wikipedia.org/wiki/Petri_net
◼ Petri Nets | SpringerLink

Cloud Computing Second Edition -

Dan C. Marinescu Chapter 3. 28
6. Process state, events, process/thread groups
◼ Dispatchable units of work:
 Process → a program in execution.
 Thread → a light-weight process.
◼ State of a process/thread → the ensemble of information we need to
restart a process/thread after it was suspended.
◼ Event → is a change of state of a process.
 Local events.
 Communication events.
◼ Process group → a collection of cooperating processes; the
processes work in concert and communicate with one another in
order to reach a common goal.
◼ The global state of a distributed system consisting of several
processes and communication channels is the union of the states of
the individual processes and channels

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 29

Messages and communication channels

◼ Message → a structured unit of information.

◼ Communication channel → provides the means for processes or
threads to communicate with one another and coordinate their
actions by exchanging messages. Communication is done only by
means of send(m) and receive(m) communication events, where m
is a message.
◼ The state of a communication channel : given two processes pi and
pj, the state of the channel ξi,j, from pi to pj consists of messages
sent by pi but not yet received by pj.
◼ Protocol → a finite set of messages exchanged among processes to
help them coordinate their actions.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 30

Space-time diagrams display local and 1
e e
2 3 4 11
e
1 1 e 1 e 1 1

communication events during a p 1

process lifetime. Local events are (a)

small black circles. Communication

events in different processes are 1 2 3 4 5
e
1 e 1 e
1 e 1 e 1
6
e
connected by lines from the send event
1
p 1

and to the receive event. 1 2 5

3 4
e e e e e
(a) All events in process p1 are local;
2 2 2 2 2
p 2

the process is in state σ1 (b)

immediately after the occurrence of

event e11 and remains in that state
until the occurrence of event e12 . 1 3 4 5
2
e e e e e
(b) Two processes p1 and p2; event e12
1 1 1 1 1

p 1

is a communication event, p1 sends

a message to p2 ; e23 is a
1 2 3 4
e
2 e 2 e 2 e
2

p 2

communication event, process p2

receives the message sent by p1. e
1
3 e
2
3 e
3
3 e
4
3

p
(c) Three processes interact by means 3

(c)
of communication events.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 31

 Events and causality
◼ Activity of any process/thread is modeled as a sequence of events.
◼ The binary relation cause-effect should be expressed in terms of events
and should support our intuition that cause must precede effects.
◼ Need to distinguish local events and communication events.
◼ Communication events affect more than one process and are essential
for constructing a global history of an ensemble of processes.
◼ Properties of the binary cause-effect relationship between two events:

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 32

Global state of a process/thread group
◼ The global states of a distributed computation with n processes form
an n-dimensional lattice.
◼ How many paths to reach a global state exist? The more paths, the
harder is to identify the events leading to a given state. A large
number of paths increases the difficulties to debug a system.
◼ In case of two threads the number of paths from the initial state Σ(0,0)
to the state Σ(m,n) is:
N (m,n) = (m + n)! /(m!n!)
◼ In the two dimensional case the global state Σ (m,n) can only be
reached from two states, Σ(m-1,n) and Σ(m,n-1)

 
(m-1,n) (m,n-1)


(m,n)

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 33

 
0, 0
1 2
e e
1 1

p
1

  p
1, 0 0 ,1
2 1 2
e e 2 2
1 2
e 1 e 1

  
2, 0 1,1 0, 2
p 1

p 2
1 2
e e
The lattice of the   
3, 0 2 ,1 1, 2 2 2
(a) 1 2
e e
global states of two 1 1

p

1

3,1 2, 2
p
processes with the 2 1
e e
2
2
2

space-time showing 
4 ,1

3, 2

2,3
e e
1
1
2
1

only the first two p

1

p
events per process.    
5,1 4, 2 3, 3 2, 4 2 1 2
e e 2 2

1 2
e e
(b) The six possible
1 1

   p

5, 2 4,3 3, 4 2,5
1

sequences of p
2 1 2
e 2 e 2

events leading to 
53

4, 4

3, 5
e
1
1
2
e
1

p
the state Σ2,2 p
1


4,5

5, 4 2 1 2
e 2 e
2

(2 + 2)! / 2!2! = 6

5, 5

time


6,5

(a) (b)

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 34

7. Communication protocols and process coordination

◼ Communication protocol → finite set of messages exchanged among

processes and threads to help them coordinate their actions.
◼ Communication protocols implement:
 Error control mechanisms – using error detection and error correction
codes.
 Flow control - provides feedback from the receiver, it forces the sender to
transmit only the amount of data the receiver can handle.
 Congestion control - ensures that the offered load of the network does not
exceed the network capacity.
◼ Error detection and error correction codes allow processes to
communicate reliably though noisy digital channels. The redundancy of
a message is increased by more bits and packaging a message as a
code word.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 35

 1
2
Process p1 Process p2
n-1
n

No protocol can guarantee coordination if any message may be lost with

probability ε.
Indeed, if a protocol consisting of n messages exists, then the protocol should
be able to function properly with n-1 messages reaching their destination, one
of them being lost.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 36

Time and time intervals

◼ Process coordination requires:

 A global concept of time shared by cooperating entities.
 The measurement of time intervals, the time elapsed between two
events.
◼ Two events in the global history may be unrelated, neither one is the
cause of the other; such events are said to be concurrent events.
◼ Local timers provide relative time measurements. An isolated system
can be characterized by its history expressed as a sequence of
events, each event corresponding to a change of the state of the
system.
◼ Global agreement on time is necessary to trigger actions that should
occur concurrently.
◼ Timestamps are often used for event ordering using a global time
base constructed on local virtual clocks.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 37

8. Logical clocks

◼ Logical clock (LC) → an abstraction necessary to ensure the clock

condition in the absence of a global clock.
◼ A process maps events to positive integers. LC(e) the local variable
associated with event e.
◼ Each process time-stamps each message m it sends with the value
of the logical clock at the time of sending:
TS(m) = LC(send(m)).
◼ The rules to update the logical clock:
LC(e) = LC + 1 if e is a local event
LC(e) = max (LC, (TS(m)+1)) if e is a receive event.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 38

 1 2 3 4 5 12
p 1

m 1 m 2 m
5

1 2 6 7 8 9
p 2

m 3 m 4

1 2 3 10 11
p 3

Three processes and their logical clocks.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 39

Message delivery rules; causal delivery

◼ The communication channel abstraction makes no assumptions about

the order of messages; a real-life network might reorder messages.
◼ First-In-First-Out (FIFO) delivery → messages are delivered in the
same order they are sent.
◼ Causal delivery → an extension of the FIFO delivery to the case when
a process receives messages from different sources.
◼ Even if the communication channel does not guarantee FIFO delivery,
FIFO delivery can be enforced by attaching a sequence number to
each message sent. The sequence numbers are also used to
reassemble messages out of individual packets.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 40

 Process Process
p i
p j

deliver
Channel/ Channel/
Process receive Process
Interface Interface
Channel

Message receiving and message delivery are two distinct operations. The
channel-process interface implements the delivery rules, e.g., FIFO delivery.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 41

 p 1

m m 3
2

p 2

m 1

p 3

Violation of causal delivery when more than two processes are involved;
message m1 is delivered to process p2 after message m3, though message m1
was sent before m3. Indeed, message m3 was sent by process p1 after
receiving m1, which in turn was sent by process p3 after sending message m1.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 42

9. Runs and cuts

◼ Run → a total ordering of all the events in the global history of a

distributed computation consistent with the local history of each
participant process; a run implies a sequence of events as well as a
sequence of global states.
◼ Cut → a subset of the local history of all processes.
◼ Frontier of the cut in the global history of n processes → an n-tuple
consisting of the last event of every process included in the cut.
◼ Cuts provide the intuition to generate global states based on an
exchange of messages between a monitor and a group of processes.
The cut represents the instance when requests to report individual
state are received by the members of the group.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 43

Consistent and inconsistent cuts and runs

◼ Consistent cut → a cut closed under the causal precedence

relationship.
◼ A consistent cut establishes an instance of a distributed computation;
given a consistent cut we can determine if an event e occurred before
the cut.
◼ Consistent run → the total ordering of events imposed by the run is
consistent with the partial order imposed by the causal relation.
◼ The causal history of event e is the smallest consistent cut of the
process group including event e.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 44

 1 2 3 4 5 6
e
1 e 1 e
1 e e
1 1 e
1

p 1

m m C 1 C 2
m
5
1 2
1 2 3 5
e
2 e
2 e
2
4
e e
2 2
6
e
2
p 2

m 3 m 4

1 2 3 4 5
e 3 e
3 e
3 e 3 e
3

p 3

Inconsistent and consistent cuts.

◼ The cut C1=(e14,e25,e32) is inconsistent because it includes e24 - the event
triggered by the arrival of the message m3 at process p2 but does not include e33,
the event triggered by process p2 sending m3 thus, the cut C1 violates causality.
◼ The cut C2=(e15,e26,e33) is consistent; there is no causal inconsistency, it includes
event e26 - the sending of message m4 without the effect of it, the event e34 - the
receiving of the message by process p3.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 45

 1 2 3 4 5 6
e
1 e 1 e
1 e e
1 1 e
1

p 1

m
1 m 2 m
5

1 2 3 5
e
2 e
2 e
2
4
e e
2 2 e
6
2
p 2

m 3 m 4

1 2 3 4 5
e 3 e
3 e
3 e
3 e
3

p 3

The causal history of event e25 is the smallest consistent cut including e25.

Q: What are the causal histories of the event and ?

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 46

10. Critical sections, locks, deadlocks, atomic actions
◼ Concurrency requires a rigorous discipline when threads access
shared resources.
◼ Only one thread should be allowed to modify shared data at any
given time and other threads should only be allowed to read or write
this data item only after the first one has finished.
◼ This process called serialization applies to segments of code called
critical sections that need to be protected by control mechanisms
called locks permitting access to one and only one thread at a time.
◼ Serialization by locking a data structure is against the very nature of
concurrency, but, without some form of concurrency control it is not
possible to guarantee the correctness of results of any computation.
◼ A deadlock occurs when processes/threads competing with one
another for resources are forced to wait for additional resources held
by other processes/threads and none of the processes/threads can
finish.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 47

 Critical section and locks
Thread k

Thread i
ACQUIRE Lock L

Lock L
Shared variable
Multi-step operation to be executed atomically

RELEASE Lock L

To enter a critical section a thread must acquire the lock of that section
and after finishing must release the lock. Only one thread should be
successful when multiple threads attempt to acquire the lock at the
same time; the other threads must wait until the lock is released.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 48

Example of Exclusive Locks

Transaction T: Transaction U:
balance = b.getBalance() balance = b.getBalance()
b.setBalance(bal*1.1) b.setBalance(bal*1.1)
a.withdraw(bal/10) c.withdraw(bal/10)
Operations Locks Operations Locks
openTransaction
100 bal = b.getBalance() lock B
b.setBalance(bal*1.1) openTransaction
110
a.withdraw(bal/10) lock A bal = b.getBalance() waits for T’s lock on B
10
closeTransaction unlock A, B
lock B
121 b.setBalance(bal*1.1)
c.withdraw(bal/10) lock C
11
REF1 Fig. 16.14 closeTransaction unlock B, C

49
Example of Exclusive Locks

Transaction T: Transaction U:
balance = b.getBalance() balance = b.getBalance()
b.setBalance(bal*1.1) b.setBalance(bal*1.1)
a.withdraw(bal/10) c.withdraw(bal/10)
Operations Locks Operations Locks
openTransaction
100 bal = b.getBalance() lock B
b.setBalance(bal*1.1) openTransaction
110
a.withdraw(bal/10) lock A 100 bal = b.getBalance() waits for T’s lock on B

closeTransaction unlock A, B
lock B
110 b.setBalance(bal*1.1)
c.withdraw(bal/10) lock C

REF1 Fig. 16.14 closeTransaction unlock B, C

50
Two-Phase Locking

◼ Remember that serial equivalence requires all pairs of conflicting

operations of two transactions should be executed in the same
order.
(1) (2) (3)
 So the pattern of “lock → unlock → lock → unlock” is not allowed,
because another transaction may perform a conflicting operation in the
middle of (2).

◼ Two-phase locking:
 Growing phase: lock → lock → … → lock
 Shrinking phase: unlock → unlock → … → unlock

◼ Strict two-phase locking:

 In order to handle aborted transactions, the applied locks can only be
released when the transaction commits or aborts, and the related
objects have been written to permanent storage.
 More details later.
51
Read Locks and Write Locks
◼ Exclusive locks prohibits concurrent read operations, which are not
conflicting.

◼ “Many readers/single writer” scheme:

 Use two types of locks: read lock and write lock
 Before a transaction performs read operation, a read lock should be set
on the object.
 Before a transaction performs write operation, a write lock should be set
on the object.

52
Lock Compatibility

The below table shows the result of a lock request for

different scenarios:
REF1 Fig. 16.15
For one object Lock requested
read write
Lock already set none OK OK
(by a different
Transaction) read OK wait
write wait wait

We can see that a write lock is more exclusive than a read lock.

53
Lock Promotion
◼ Inside a single transaction, it is possible to first read an object and
then write the same object.
 So it sets a read lock on the object, and then sets a write lock on the
object.
 Instead of using two locks on the same object at the same time, we can
simply “promote” the original read lock to the more exclusive write lock.
 However, if the read lock is shared with other transaction(s), it cannot
be promoted because the write operation conflicts with the read
operation of other transaction(s). The transaction must request a write
lock and wait for other read locks to be released.

54
 Strict Two-Phase Locking

1. When an operation accesses an object within a transaction:

(a) If the object is not already locked, it is locked and the operation proceeds.
(b) If the object has a conflicting lock set by another transaction, the
transaction must wait until it is unlocked.
(c) If the object has a non-conflicting lock set by another transaction, the lock
is shared and the operation proceeds.
(d) If the object has already been locked in the same transaction, the lock will
be promoted if necessary and the operation proceeds. (Where promotion is
prevented by a conflicting lock, rule (b) is used.)

2. When a transaction is committed or aborted, the server unlocks all objects it

locked for the transaction.

55
Deadlocks
◼ The use of locks can lead to deadlock

Transaction T Transaction U

Operations Locks Operations Locks

a.deposit(100); write lock A

b.deposit(200) write lock B
b.withdraw(100)
waits for U’s
a.withdraw(200); waits for T’s
lock on B
lock on A

56
Wait-for Graph
◼ A wait-for graph can be used to represent the waiting relationships
between current transactions.
 Nodes represent transactions.
 Edges represent wait-for relationships.

◼ A cycle in the wait-for graph indicates a deadlock.

Held by Waits for

A
T U T U

Waits for B
Held by

57
Conditions for Deadlock Occurs
◼ Mutual Exclusion
 Some resources are locked
◼ Hold and Wait
 Some process is holds some resource and waits for some other
resources held by other processes.
◼ No Preemption
 Once resource is allocated, it cannot be preempted/taken back.
◼ Circular Wait
 The waiting is in a circular manner.

58
Deadlock Prevention - Breaking the Conditions
◼ Mutual Exclusion
 Resources are many enough. No sharing is needed
◼ Hold and Wait
 A process request all resources at a time (inefficient)
 Take one resource at a time (not realistic, non serial equivalent)
◼ No Preemption
 Process with higher priority can overtake resource
 May need to rollback transaction.
◼ Circular Wait
 Label each resource with an integer. Lock resources in an ascending
order. (may cause starvation)

59
Deadlock Avoidance
◼ Every process is to declare its maximum need of locks at the
beginning.
◼ Coordinator keeps the record and decides to entertain a new
request only if it will not transit to an unsafe state.
 N: number of processes
 M: number of resources
 Av[]: array of each resource availabile
 Dcl[][]: 2D array of resources needed by each process
 Allo[][]: 2D array of resources currently allocated to each process
 Need[][]: Av[][] – Allo[][], the resource shorts of.

60
 Banker’s Safety Algorithm

◼ P1 finishes first (need 2A + 1B + 1D),

Avaliable Resource, Av[]
item A B C D
then it releases all resources.
Avaliable 3 1 0 2
◼ Av[] becomes 4A+3B+2C+3D, enough
Require Resource Declared, Dcl[] for P2 to finish and P2 releases all
PID \ i A B C D
P1 3 3 2 2
resources.
P2 1 2 3 4
P3 1 3 5 0
◼ Av[] becomes 5A+3B+5C+6D, enough
for P3 to finish.
Currently Allocated, Allo[][]
PID \ i A B C D ◼ All process can finish => Safe
P1 1 2 2 1
P2 1 0 3 3
P3 1 2 2 0

Resources Shorts-of, Need[][] = Dcl[][] - Allo[][]

PID \ i A B C D
P1 2 1 0 1
P2 0 2 0 1
P3 0 1 3 0

61
 Banker’s Safety Algorithm

Avaliable Resource, Av[] ◼ P2 starts first (P1 & P3 not enough

item A B C D
Avaliable 3 1 0 2
resources to start)
Require Resource Declared, Dcl[]
◼ P2 releases after finishing, Av[]
PID \ i A B C D becomes 4A+1B+3C+5D
P1 3 4 2 2
P2 1 1 3 4 ◼ Still not enough for P1 (short 1B) or
P3 1 3 5 0
P3 (short 1C)
Currently Allocated, Allo[][]
PID \ i A B C D
◼ Unsafe.
P1 1 2 2 1
P2 1 0 3 3
P3 1 2 1 0

Resources Shorts-of, Need[][] = Dcl[][] - Allo[][]

PID \ i A B C D
P1 2 2 0 1
P2 0 1 0 1
P3 0 1 4 0

62
Deadlock Detection and Timeouts
◼ Deadlock detection:
 Find cycles in the wait-for graph
 Select a transaction for abortion to break the cycle

◼ Timeouts:
 Breaks “Hold and Wait” condition
 Each lock is given a limited period in which it is invulnerable.
 After this time, a lock becomes vulnerable.
◼ If no other transaction is competing for the locked object, it remains
locked.
◼ However, if any other transactions is waiting to access this object,
the lock is broken and the waiting transaction resumes. The
transaction whose lock has been broken is aborted.

63
Timeout

Can you see the problem?

64
Problems associated with aborting transactions:
 Dirty Reads:

 Premature Writes:
; Restore the old value of a

commit transaction
65 abort transaction; Restore the old value of a
Runs, cuts and atomic actions.
◼ I don't cover these concepts in the course;
◼ If you are interested, you can refer to the hidden slides.

◼ Let's take a break before the exam.

Dan C. Marinescu 66
 Atomic actions

◼ Parallel and distributed applications must take special precautions

for handling shared resources.
◼ Atomic operation → a multi-step operation should be allowed to
proceed to completion without any interruptions and should not
expose the state of the system until the action is completed.
◼ Hiding the internal state of an atomic action reduces the number of
states a system can be in thus, it simplifies the design and
maintenance of the system.
◼ Atomicity requires hardware support:
 Test-and-Set → instruction which writes to a memory location and
returns the old content of that memory cell as non-interruptible.
 Compare-and-Swap → instruction which compares the contents of a
memory location to a given value and, only if the two values are the
same, modifies the contents of that memory location to a given new
value.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 67

All-or-nothing atomicity

◼ Either the entire atomic action is carried out, or the system is left in the
same state it was before the atomic action was attempted;
a transaction is either carried out successfully, or the record targeted by
the transaction is returned to its original state.
◼ Two phases:
 Pre-commit → during this phase it should be possible to back up from it
without leaving any trace. Commit point - the transition from the first to the
second phase. During the pre-commit phase all steps necessary to prepare
the post-commit phase, e.g., check permissions, swap in main memory all
pages that may be needed, mount removable media, and allocate stack
space must be carried out; during this phase no results should be exposed
and no actions that are irreversible should be carried out.
 Post-commit phase → should be able to run to completion. Shared
resources allocated during the pre-commit cannot be released until after
the commit point.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 68

 Commit Committed
New action
Pending Discarded

Abort Aborted

The states of an all-or-nothing action.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 69

Atomicity
◼ Before-or-after atomicity → the effect of multiple actions is as if
these actions have occurred one after another, in some order.
◼ A systematic approach to atomicity must address several delicate
questions:
 How to guarantee that only one atomic action has access to a shared
resource at any given time.
 How to return to the original state of the system when an atomic action
fails to complete.
 How to ensure that the order of several atomic actions leads to
consistent results.

Dan C. Marinescu Cloud Computing Second Edition - Chapter 3. 70