Concurrency - Rose

Day 13
Concurrency
Concurrency

Single-processor, multi-programmed systems




Interleaving processes
More efficient utilization of the processor
Results in better system performance.
Multi-processor systems


Processes run at the same instance of time on
different processors
Interleaving and overlapping processes
Problems

Relative speed of execution of processes cannot
be predicted – do not know which process will run
next.


Variables and resources shared by processes.
OS has more difficulty allocating resources.


For example, a process requests a communication link, gets the
link, but then times out. Should the OS give the communication
link to some other process?
Difficult to locate programming errors as program behavior
cannot be replicated.
Race condition

A condition where two or more
threads/processes modify a shared resource
and the final result depends on the relative
timing of their execution.
Example 1: A program with threads
A mail server for an organization manages the e-mail.
The mail-server has to keep track of the number of emails received from the start of the day. The receipt of
an e-mail is handled by one of the several worker
threads. Each time an e-mail is received, the thread
must update MAILCOUNT using the following
assembly language routine.
LOAD MailCount
ADD 1
STORE MailCount
#Acc = Mem[MailCount]
#Acc= Acc + 1
# Mem[MailCount] = Acc
Mem[Mailcount] = 25;
Thread 1
Load MailCount # Acc = 25
Add 1
# Acc = Acc + 1 = 26;
Thread 2
Load MailCount
# Acc = 25
Add 1
# Acc = Acc+ 1 = 26
Store MailCount # Mem[MailCount] = 26
Store MailCount
# Mem[MailCount] = 26
Problem 1
Given the following code segment that is shared by two processes,
show with a sequence of executions, how a race condition can
affect the output of the two processes when they concurrently
access the shared code and data. Assume a single-processor,
multi-programmed system.
void echo(){
chin = getchar(); //Accept keyboard input.
chout = chin;
putchar(chout); //Display input value to the output device
}
What’s causing the
problem?
•
When using shared variables and shared routines
•
Process behavior or thread behavior
•
•
must be predictable
must be independent of the speed at which its execution is
carried out relative to the speed of other concurrent processes.
How would you prevent the
problem?
How to prevent the problem?



Restrict access to shared variables and
resources such that only when a process/ thread
has completed execution of the shared code (i.e.
checking, modifying and reacting to a shared
variable) will another process be allowed to
execute the shared code.
The shared code that has to be protected is called
the critical section.
The principle of allowing one process/thread
access to a critical resource at a given time is
called mutual exclusion.




Critical section – A section of code that requires access to
shared resources and that may not be executed while another
process is in a corresponding section of code that accesses the
same shared resources.
Mutual exclusion – The requirement that while one process is in
a CS that accesses shared resources, no other process may be
in a CS that accesses the same set of shared resources.
Race condition – A condition where two or more
threads/processes modify a shared resource and the final result
depends on the relative timing of their execution.
Deadlock – Processes are permanently blocked and waiting on
events that can only be triggered by other blocked processes
How do processes interact with
each other?




Processes unaware of each other are said to be in competition
with each other.
They are independent of each other, do not share code or
variables. May require common resources, e.g., a disk block or a
printer.
Influence on other processes
 Output will not be affected
 Processes may experience delay
Control problems faced
 Need for mutual exclusion
 Deadlock prevention
 Starvation
How do processes interact with
each other?











Processes indirectly aware of each other
Any process that accesses shared data or code knows that
other processes are potentially modifying/accessing the shared
data/code.
Such processes are said to co-operate by sharing.
Influence on other processes
Outputs may be interdependent
A process may experience delay
Control problems
Mutex, deadlock, and starvation
Also,
Data is accessed both for read and write. Write accesses need
to be mutually exclusive.
Data coherence needs to be maintained
How do processes interact with
each other?





Processes directly aware of each other may communicate
directly with each other and are said to co-operate using
communication.
Processes are not competing. Have a common goal and cooperate.
Mutual exclusion need not be enforced since there is typically
no common data or resource.
Communication is through message passing primitives.
Can cause deadlock and starvation


e.g. 1: Two processes are both blocked waiting for
communication from each other.
e.g. 2: P1 with P2 and P3. P1 and P2 keep on comm.. and P1
does not get a chance to send a message to P3. So, P3 starves.
Requirements for a mutual
exclusion solution






Enforce mutex
A process that halts in its CS must not block other
processes indefinitely.
Process waiting for CS must not be waiting
indefinitely – no deadlock, no starvation
If there is no process in the CS, no process wanting
to enter the CS must be denied access.
No assumptions are made about the relative speeds
or number of processes.
A process may remain in its CS for a finite period of
time.
Four different approaches




Hardware support
Software-defined approaches
Support from the OS
Support from the programming language.
Enforcing Mutual Exclusion
Funtion(){
<non-CS>
enter_critical_section();
<CS>
exit_critical_section();
<non-CS>
}
1. Hardware support
void func(){
<non-CS>
/* disable interrupts */
<CS>
/* enable interrupts */
<non–CS>
}
Disadvantages
•
If the critical section is long, then control is
taken away from the OS for a large period of
time.
•
•
This decreases overall system performance.
Will not work on multi-processor systems.
2. Hardware support - special
machine instructions
Machine instruction:
boolean testset(i){
if(i==0){
i=1;
return true;
}
else
return false;
}
int bolt = 0;
void main(){
parbegin(P(0),P(1)…P(n))
}
void P(int j){
while(testset(bolt)!= true)
{do nothing}
<CS>
bolt = 0;
<non-CS>
}