1

Chapter 5 – Asynchronous Concurrent

Execution

Modified by D. Khaled W. Mahmoud

2009/2010

 2004 Deitel & Associates, Inc. All rights reserved.

 2

5.1 Introduction

• General-purpose languages such as Java, C#, and

Python have made concurrency primitives available
to applications programmer
• Multithreading
– Programmer specifies applications contain threads of execution
– Each thread designate a portion of a program that may execute
concurrently with other threads

We will focus on threads, but most of what we say

apply to processes

 2004 Deitel & Associates, Inc. All rights reserved.

 3

5.1 Introduction

• Concurrent execution
– More than one thread exists in system at once
– Can execute independently or in cooperation
• Asynchronous execution
• Threads generally independent
• Must occasionally communicate or synchronize
• Complex and difficult to manage such interactions

 2004 Deitel & Associates, Inc. All rights reserved.

 4

5.2 Mutual Exclusion

• Example
– two threads concurrently increment the value of a specific
variable by using the following instructions:
• Read the variable
• Inc by 1
• Write the variable
– Due to quantum expire, the first thread loses the processor (after
executing the second line and before writing the value).
– The second thread executes the three instructions, and then
switch back to the first thread.
• What will be the value of this variable?

 2004 Deitel & Associates, Inc. All rights reserved.

 5

5.2 Mutual Exclusion

• Problem of two threads accessing data simultaneously

– Data can be put in inconsistent state
• Context switch can occur at anytime, such as before a thread
finishes modifying value
• Reading vs. Writing
– Such data must be accessed in mutually exclusive way
• Only one thread allowed access at one time
• Others must wait until resource is unlocked
– This is called Serialized accessed to shared variable
– Must be managed such that wait time not unreasonable

 2004 Deitel & Associates, Inc. All rights reserved.

 6

5.2.2 Critical Sections

• When a process is accessing shared data, the process

is said to be in its critical section.
• Only one thread can be in its critical section at once
– All other threads currently requiring access to shared data are
kept waiting
– Must execute quickly as possible.
– A process must not block within its critical section.
– Must be careful to avoid infinite loops and blocking inside a
critical section

 2004 Deitel & Associates, Inc. All rights reserved.

 7

5.2.3 Mutual Exclusion Primitives

• Indicate when critical data is about to be accessed

– Mechanisms are normally provided by programming language or
libraries
– Delimit beginning and end of critical section
• enterMutualExclusion
• exitMutualExclusion
– Example:
While (true) {
Receive e-mail
enterMutualExclusion
Count++
exitMutualExclusion
}
• Explain: Two threads (T1, T2)
– T1 enter its critical section while T2 is in/outside its critical
sections

 2004 Deitel & Associates, Inc. All rights reserved.

 8

5.3 Implementing Mutual Exclusion Primitives

• Common properties of mutual exclusion primitives

– The solution is implemented purely in software
– Cannot make assumptions about relative speed of thread
execution
– Thread not in its critical section cannot block other threads from
entering their critical sections
– Thread may not be indefinitely postponed from entering its
critical section

 2004 Deitel & Associates, Inc. All rights reserved.

 9

5.4.1 Dekker’s Algorithm

• Version one.
• Version two.
• Version three.
• Version four.
• Final version/Dekker’s Algorithm.

 2004 Deitel & Associates, Inc. All rights reserved.

 10

5.4.1 Dekker’s Algorithm

• First version of Dekker’s algorithm (Next Slide)

– Succeeds in enforcing mutual exclusion
– Uses variable to control which thread can execute
– Constantly tests whether critical section is available
• Busy waiting (Wastes significant processor time)
– Process one must go first, while process two is busy waiting.
– Processes must enter and leave their CS in strict alteration.
• Problem known as lockstep synchronization
• If one thread needs to enter its CS more frequently than the other,
the faster thread will be constrained to operate at the speed of the
slower thread.

 2004 Deitel & Associates, Inc. All rights reserved.

 11

5.4.1 Dekker’s Algorithm

Figure 5.6 Mutual exclusion implementation – version 1

Set a shared variable turn (initialized to 1). If turn=i then thread i

is allowed to enter the critical section

 2004 Deitel & Associates, Inc. All rights reserved.

 12

5.4.1 Dekker’s Algorithm

• Second version
– Removes lockstep synchronization
– Violates mutual exclusion
• Thread could be preempted while updating flag variable
– Not an appropriate solution
• What happens if both t1Inside and t2Inside are false and both
threads attempt to enter their critical section at the same time?
– t1 tests the value of t2Inside
– t1 lose processor before executing t1Inside=true
– t2 now is executed and enter its CS
– T1 return back and enter its critical section
• i.e. while a process is testing the while condition to set a flag that it
is inside its CS , there is enough time for the other process to test
its flag and slip into its CS.

 2004 Deitel & Associates, Inc. All rights reserved.

 13

5.4.1 Dekker’s Algorithm

Figure 5.7 Mutual exclusion implementation – version 2
Replace the variable turn with the two variables:
boolean t1Inside = false; boolean t2Inside = false;
tiInside = true indicates that thread i is inside the critical section.

 2004 Deitel & Associates, Inc. All rights reserved.

 14

5.4.1 Dekker’s Algorithm

• Third version
– Set critical section flag before entering critical section test
• Once again guarantees mutual exclusion
– Introduces possibility of deadlock
• It is possible for the following situation to happen:
– thread 1: set t1WantToEnter = true;
– thread 2: set t2WantToEnter = true;
– Thread 1 and 2 will loop forever in the while statement
– Neither would ever be able to break out of loop
– Not a solution to the mutual exclusion problem

deadlock: state of a thread when it cannot continue

execution because its waiting for an event the will
never occur.
Indefinite Postponement: Situation in which a threads
waits for an event that might never occur

 2004 Deitel & Associates, Inc. All rights reserved.

 15

5.4.1 Dekker’s Algorithm

Figure 5.8 Mutual exclusion implementation – version 3

Replace the variables t1Inside and t2Inside with the two variables:
boolean t1WantToEnter = false; boolean t2WantToEnter = false;
tiWantToEnter = true indicates that thread i desires to enter the CS.

 2004 Deitel & Associates, Inc. All rights reserved.

 16

5.4.1 Dekker’s Algorithm

• Fourth version
– Sets flag to false for small periods of time to yield control
– Solves previous problems, introduces indefinite postponement
• Both threads could set flags to same values at same time (same
speed -- unlikely but possible)

 2004 Deitel & Associates, Inc. All rights reserved.

 17

5.4.1 Dekker’s Algorithm: version 4

 2004 Deitel & Associates, Inc. All rights reserved.

 18

5.4.1 Dekker’s Algorithm

• Dekker’s Algorithm (Proper solution)

– Uses notion of favored threads to determine entry into critical
sections
• Resolves conflict over which thread should execute first
• Each thread temporarily unsets critical section request flag
• Favored status alternates between threads
– Guarantees mutual exclusion
– Avoids previous problems of deadlock, indefinite postponement

 2004 Deitel & Associates, Inc. All rights reserved.

 19

5.4.1 Dekker’s Algorithm

• A boolean variable for each thread to indicate its

desire to enter the critical section:
– boolean t1WantToEnter = false;
– boolean t2WantToEnter = false;
• An int variable to indicate the favoured thread that
will enter the critical section.
– int favouredThread = 1;

 2004 Deitel & Associates, Inc. All rights reserved.

 20

5.4.1 Dekker’s Algorithm: Proper solution

Thread 1 Thread 2
while(true){ while(true){
t1WantToEnter=true; t2WantToEnter=true;
while(t2WantToEnter) { while(t1WantToEnter) {
if(favouredThread==2){ if(favouredThread==1)
t1WantToEnter=false; t2WantToEnter=false;
while(favouredThread==2) while(favouredThread==1)
{wait;} {wait;}
t1WantToEnter=true; t2WantToEnter=true;
} } } }
critical section; critical section;
favouredThread=2; favouredThread=1;
t1WantToEnter=false; t2WantToEnter=false;
non-critical section; non-critical section;
} }

 2004 Deitel & Associates, Inc. All rights reserved.

 21

5.4.1 Dekker’s Algorithm: Proper solution

• T1 wants to enter its CS while T2 doesnot.

• T1 and t2 wants to enter CS and T1 is the favorite
thread
• T1 and t2 wants to enter CS and T2 is the favorite
thread.

 2004 Deitel & Associates, Inc. All rights reserved.

 22

5.5 Hardware Solutions to the Mutual Exclusion

• Implementing mutual exclusion in hardware

– Can improve performance
– Can decreased development time
• No need to implement complex software mutual exclusion
solutions

 2004 Deitel & Associates, Inc. All rights reserved.

 23

5.5.2 Test-and-Set Instruction

• A special hardware instruction – Test-and-Set

instruction enables a thread to perform some
operations atomically.
– once initiated will complete all of these functions without
interruption
• Test-and-set instruction
– testAndSet(a, b) copies the value of b to a, then sets b to
true

 2004 Deitel & Associates, Inc. All rights reserved.

 24

5.5.2 Test-and-Set Instruction

Boolean occupied = false
Thread 1 Thread 2
void main() { void main() {
boolean p1MustWait = true; boolean p2MustWait = true;
while (true) { while (true) {
while (p1MustWait){ while (p2MustWait){
testAndSet(p1MustWait, testAndSet(p2MustWait,
occupied) occupied)
} }
//critical section //critical section
p1MustWait = true; p2MustWait = true;
occupied = false; occupied = false;
//code outside CS //code outside CS
}} }}

 2004 Deitel & Associates, Inc. All rights reserved.

 25

5.5.2 Test-and-Set Instruction

• T1 wants to enter its CS while T2 doesnot

• T1 in its CS and T2 wants to enter CS

 2004 Deitel & Associates, Inc. All rights reserved.

 26

5.6 Semaphores

• Semaphores
– A semaphore is an integer protected variable that, apart from
initialization, is accessed only through two standard operations:
P(wait) and V(signal)
• Binary semaphores can assume only the value 0 or
the value 1.
• Semaphores can be implemented in software or
hardware, but they are commonly implemented in the
nucleus of the O.S

 2004 Deitel & Associates, Inc. All rights reserved.

 27

5.6 Semaphores

Definitions of P(S) and V (S):

wait operation on semaphore S (Enter CS)
P(S){
if (S>0)
S=S-1
else
put the calling thread into the semaphore S’s waiting queue
}

Exit mutual exclusion (signal)

V(S){
if any threads are waiting in the semaphore S’s waiting queue
Resume the “next” waiting thread from the queue
else
S=S+1
}

 2004 Deitel & Associates, Inc. All rights reserved.

 28

5.6.1 Mutual Exclusion with Semaphores

Figure 5.15 Mutual exclusion with semaphores.

 2004 Deitel & Associates, Inc. All rights reserved.

 29

5.6.2 Thread Synchronization with Semaphores

• Semaphores can be used to notify other threads that

events have occurred
• Suppose one process, a producer, is generating
information that a second process, a consumer, is
using.
• Producer enters its critical section to produce value
– Consumer is blocked until producer finishes
• Consumer enters its critical section to read value
– Producer cannot update value until it is consumed
– Semaphores offer a clear, easy-to-implement solution to this
problem

 2004 Deitel & Associates, Inc. All rights reserved.

 30

5.6.2 Thread Synchronization with Semaphores

 2004 Deitel & Associates, Inc. All rights reserved.

 31

5.6.2 Thread Synchronization with Semaphores

Use semaphore to notify the occurrence of an event:

• Use a semaphore S, initialized to 0.
• T1: P(S), this causes T1 to block
• T2: V(S), this signals the occurrence of the event and
allows T1 to proceed.

 2004 Deitel & Associates, Inc. All rights reserved.

 32

5.6.2 Thread Synchronization with Semaphores

Global variables:
• Semaphore valueProduced for the “value has been produced”
event. It is initialized to 0.
• Semaphore valueConsumed for the “value has been
consumed” event. It is initialized to 1.
• int sharedValue is a variable shared by both producer and
consumer threads.

 2004 Deitel & Associates, Inc. All rights reserved.

 33

5.6.2 Thread Synchronization with Semaphores

Main(){
int nextValueProduced
While(true){
nextValueProduced = generate a new value
P(valueConsumed)
sharedValue = nextValueProduced;
V(valueProduced)
} Consumer
}
Main(){
int nextValueConsumed
Producer While(true){
P(valueProduced)
nextValueConsumed = sharedValue
V(valueConsumed);
process the value
}
}

 2004 Deitel & Associates, Inc. All rights reserved.

 34

5.6.3 Counting Semaphores

• Counting semaphores
– Initialized with values greater than one
– Can be used to control access to a pool of identical resources
• Decrement the semaphore’s counter when taking resource from
pool
• Increment the semaphore’s counter when returning it to pool
• If no resources are available, thread is blocked until a resource
becomes available

 2004 Deitel & Associates, Inc. All rights reserved.