Process
Concurrency
Roadmap
• Principals of Concurrency
• Mutual Exclusion: Hardware Support
• Mutual Exclusion: Software Support
• Semaphores
• Monitors
• Message Passing
• Readers/Writers Problem
Principles of Concurrency
• Central themes of operating system design are all concerned with
the management of processes and threads
– Multiprogramming - management of multiple processes within a
uniprocessor system
– Multiprocessing - management of multiple processes within a
multiprocessor system
– Distributed Processing - management of multiple processes executing
on multiple, distributed computer systems.
• Fundamental to all of these areas, and fundamental to OS design, is
concurrency.
• Big Issue is Concurrency
– Managing the interaction of all of these processes
• Concurrency is interleaving of processes in time to give the
appearance of simultaneous execution
Interleaving and
Overlapping Processes
• Processes may be interleaved on
uniprocessors
Interleaving and
Overlapping Processes
• And not only interleaved but overlapped
on multi-processors
Difficulties of Concurrency
• Sharing of global resources
• Optimally managing the allocation of
resources
• Difficult to locate programming errors as
results are not deterministic and
reproducible.
A Simple Example
void echo()
{
chin = getchar();
chout = chin;
putchar(chout);
}
A Simple Example:
On a Multiprocessor
Process P1 Process P2
. .
chin = getchar(); .
. chin = getchar();
chout = chin; chout = chin;
putchar(chout); .
. putchar(chout);
. .
Enforce Single Access
• If we enforce a rule that only one process
may enter the function at a time then:
• P1 & P2 run on separate processors
• P1 enters echo first,
– P2 tries to enter but is blocked – P2 suspends
• P1 completes execution
– P2 resumes and executes echo
Race Condition
• A race condition occurs when
– Multiple processes or threads read and write
data items
– They do so in a way where the final result
depends on the order of execution of the
processes.
• The output depends on who finishes the
race last.
Example of Race Condition
• B=1 ; c=2
– P3 – b=b+c
– P4 – c=b+c
– P3 -> P4 : b=3 c=5
– P4 -> P3 : b=4 c=3
• A=2
– P3 = a=a+1 =3
– P4 = a=a+2 =5
Operating System
Concerns
• What design and management issues are
raised by the existence of concurrency?
• The OS must
– Keep track of various processes
– Allocate and de-allocate resources
– Protect the data and resources against
interference by other processes.
– Ensure that the processes and outputs are
independent of the processing speed
Critical Section Problem
• Each process has segment of code called as Critical Section
• CS avoids race condition
• In CS, process may change variables, update a table, write a file, etc.
• At any moment, only one process can execute in CS
• When one process is executing in CS, no other process is allowed to
execute in its CS.
• Any solution to CS problem must satisfy the following requirements :
• Mutual exclusion : When one process is executing in CS, no other
process is allowed to execute in its CS.
• Progress : If no process is executing in its CS, and if there are some
processes that wish to enter CS, then one of these processes will get
into CS.
• Above mentioned both the conditions are mandatory conditions
• Bounded Waiting : A process cannot be denied access to CS
indefinitely. Each process must have a limited waiting time. It should
not wait endlessly to access the critical section.
Do • Mutual Exclusion
{ • Progress
Non CS code • Bounded Wait
Enter CS
Critical Section
Exit CS
Remainder section
} while(1)
Competition among
Processes for Resources
Three main control problems:
• Need for Mutual Exclusion
– Critical sections
• Deadlock
• Starvation
Competition among
Processes for Resources
Requirements for
Mutual Exclusion
• Only one process at a time is allowed in the critical
section for a resource
• A process that halts in its noncritical section must do so
without interfering with other processes
• No deadlock or starvation
• A process must not be delayed access to a critical
section when there is no other process using it
• No assumptions are made about relative process speeds
or number of processes
• A process remains inside its critical section for a finite
time only
• P1 (count no of even • P2 (count no of odd
nos) nos)
- -
- -
- -
Count++ -
- Count++
- -
- -
Roadmap
• Principals of Concurrency
• Mutual Exclusion: Hardware Support.
• Mutual Exclusion: Software Support
• Semaphores
• Monitors
• Message Passing
• Readers/Writers Problem
Disabling Interrupts
• Uniprocessors only allow interleaving
• Interrupt Disabling
– A process runs until it invokes an operating
system service or until it is interrupted
– Disabling interrupts guarantees mutual
exclusion
– Will not work in multiprocessor architecture
Pseudo-Code
while (true) {
/* disable interrupts */;
/* critical section */;
/* enable interrupts */;
/* remainder */;
}
Special Machine
Instructions
• Test & Set Instruction
• Compare & Swap Instruction
– also called a “compare and exchange
instruction”
• Exchange Instruction
Test & Set Instruction
boolean lock=false;
...
void critical()
{
while(lock==true)
{
//while another process is in CS
//do nothing (Busy Wait)
}
lock=true; //Entering CS
}
void leaveCritical()
{
lock=false; //set lock to 0 and allow other process in
}
Test & Set Instruction
Assembly code
enter_CS:
TSL register , flag;
CMP register , #0;
JNZ enter_CS;
RET;
leave_CS:
MOV flag , #0;
RET
Mutual Exclusion
Exchange Instruction
void exchange ( int *register, int *memory)
{
int temp;
temp = *memory;
*memory = *register;
*register = temp;
}
Mutual Exclusion
Hardware Mutual
Exclusion: Advantages
• Applicable to any number of processes on
either a single processor or multiple
processors sharing main memory
• It is simple and therefore easy to verify
• It can be used to support multiple critical
sections
Hardware Mutual
Exclusion: Disadvantages
• Busy-waiting consumes processor time
• Starvation is possible when a process
leaves a critical section and more than one
process is waiting.
– Some process could indefinitely be denied
access.
• Deadlock is possible
Roadmap
• Principals of Concurrency
• Mutual Exclusion: Hardware Support
• Mutual Exclusion: Software Support
• Semaphores
• Monitors
• Message Passing
• Readers/Writers Problem
Software Approaches
• Two-process solution (Using turn variable)
• Two-process solution (Using flag variable)
• Peterson’s Algorithm
• Dekker’s Algorithm
Two Process Solution using turn
P0 P1
while(1) while(1)
{ {
while(turn!=0); while(turn!=1);
Critical Section Critical Section
turn=1; // exit CS turn=0; // exit CS
remainder section remainder section
} }
Two Process Solution using flag
P0 P1
while(1) while(1)
{ {
flag[0]=T flag[1]=T
while(flag[1]); while(flag[0]);
Critical Section Critical Section
flag[0]=F // exit CS flag[1]=F // exit CS
} }
flag P0 P1
F F
T F
T T
F T
Dekker’s Algorithm
P0 P1
while(1) while(1)
{ {
flag[0]=true; flag[1]=true;
while(flag[1]) while(flag[0])
{ {
if(turn!=0) if(turn!=1)
{ {
flag[0]=false; flag[1]=false;
while(turn!=0); while(turn!=1);
flag[0]=true; flag[1]=true;
} }
} }
P0 P1 turn
Critical Section Critical Section
turn=1; turn=0; F F 0/1
flag[0]=false; flag[1]=false; T F 0
remainder remainder T T 0
} }
F T 1
F F
Peterson’s Algorithm
P0 P1
do do
{ {
flag[0]=true; flag[1]=true;
turn=1; turn=0;
while(flag[1] && turn==1); while(flag[0] && turn==0);
Critical Section Critical Section
flag[0]=false; flag[1]=false;
remainder remainder
}while(1) }while(1)
flag P0 P1 turn
F F 0/1
P0 wants to enter CS T F 1
T T 0 P1 wants to enter CS
P0 exits CS F T 0 P1 enters CS
F F
Roadmap
• Principals of Concurrency
• Mutual Exclusion: Hardware Support
• Semaphores
• Monitors
• Message Passing
• Readers/Writers Problem
Semaphore
• Semaphore:
– An integer value used for signalling among
processes.
• Only three operations may be performed
on a semaphore, all of which are atomic:
– initialize,
– Decrement (Wait)
– increment. (Signal)
Counting Semaphore
Primitives
Binary Semaphore
Primitives
Mutex
• Some Binary semaphores are called as mutex or mutex
locks
• A process that locks the mutex must be the one to
unlock it.
do
{
wait(mutex);
//Critical Section
signal(mutex);
//exit critical section
remainder section
}while(true);
Strong/Weak
Semaphore
• A queue is used to hold processes waiting
on the semaphore
– In what order are processes removed from
the queue?
• Strong Semaphores use FIFO
• Weak Semaphores don’t specify the
order of removal from the queue
Example of Strong
Semaphore Mechanism
Example of Semaphore
Mechanism
Mutual Exclusion Using
Semaphores
Processes Using
Semaphore
Producer/Consumer
Problem
• General Situation:
– One or more producers are generating data and
placing these in a buffer
– A single consumer is taking items out of the buffer
one at time
– Only one producer or consumer may access the
buffer at any one time
• The Problem:
– Ensure that the Producer can’t add data into full buffer
and consumer can’t remove data from empty buffer
Producer/Consumer Problem
mutex buffer_mutex;
semaphore fillCount = 0;
semaphore emptyCount = BUFFER_SIZE;
procedure producer()
{
while (true)
{
item = produceItem();
down(emptyCount);
down(buffer_mutex);
putItemIntoBuffer(item);
up(buffer_mutex);
up(fillCount);
}
}
Producer/Consumer Problem
procedure consumer()
{
while (true)
{
down(fillCount);
down(buffer_mutex);
item = removeItemFromBuffer();
up(buffer_mutex);
up(emptyCount);
consumeItem(item);
}
}
Roadmap
• Principals of Concurrency
• Mutual Exclusion: Hardware Support
• Semaphores
• Monitors
• Message Passing
• Readers/Writers Problem
Monitors
• The monitor is a programming-language
construct that provides equivalent
functionality to that of semaphores and
that is easier to control.
• Implemented in a number of programming
languages, including
– Concurrent Pascal, Pascal-Plus,
– Modula-2, Modula-3, and Java.
Chief characteristics
• Local data variables are accessible only
by the monitor
• Process enters monitor by invoking one of
its procedures
• Only one process may be executing in the
monitor at a time
Synchronization
• Synchronisation achieved by condition
variables within a monitor
– only accessible by the monitor.
• Monitor Functions:
–Cwait(c): Suspend execution of the calling
process on condition c
–Csignal(c) Resume execution of some
process blocked after a cwait on the same
condition
Structure of a Monitor
Bounded Buffer Solution
Using Monitor
Solution Using Monitor
Roadmap
• Principals of Concurrency
• Mutual Exclusion: Hardware Support
• Semaphores
• Monitors
• Message Passing
• Readers/Writers Problem
Process Interaction
• When processes interact with one another,
two fundamental requirements must be
satisfied:
– synchronization and
– communication.
• Message Passing is one solution to the
second requirement
– Added bonus: It works with shared memory
and with distributed systems
Message Passing
• The actual function of message passing is
normally provided in the form of a pair of
primitives:
• send (destination, message)
• receive (source, message)
Synchronization
• Communication requires synchronization
– Sender must send before receiver can receive
• What happens to a process after it issues
a send or receive primitive?
– Sender and receiver may or may not be
blocking (waiting for message)
Blocking send,
Blocking receive
• Both sender and receiver are blocked until
message is delivered
• Known as a rendezvous
• Allows for tight synchronization between
processes.
Non-blocking Send
• More natural for many concurrent
programming tasks.
• Nonblocking send, blocking receive
– Sender continues on
– Receiver is blocked until the requested
message arrives
• Nonblocking send, nonblocking receive
– Neither party is required to wait
Addressing
• Sendin process need to be able to specify
which process should receive the
message
– Direct addressing
– Indirect Addressing
Direct Addressing
• Send primitive includes a specific identifier
of the destination process
• Receive primitive could know ahead of
time which process a message is
expected
• Receive primitive could use source
parameter to return a value when the
receive operation has been performed
Indirect addressing
• Messages are sent to a shared data
structure consisting of queues
• Queues are called mailboxes
• One process sends a message to the
mailbox and the other process picks up
the message from the mailbox
Indirect Process
Communication
General Message Format
Mutual Exclusion Using
Messages
Producer/Consumer
Messages
Roadmap
• Principals of Concurrency
• Mutual Exclusion: Hardware Support
• Semaphores
• Monitors
• Message Passing
• Readers/Writers Problem
Classical Problems of
Synchronization
• Classical problems used to test
newly-proposed synchronization
schemes
– Bounded-Buffer Problem
– Readers and Writers Problem
– Dining-Philosophers Problem
Bounded-Buffer Problem
• nbuffers, each can hold one item
• Semaphore mutex initialized to the
value 1
• Semaphore full initialized to the
value 0
• Semaphore empty initialized to the
value n
Bounded Buffer Problem
(Cont.)
• The structure of the producer process
while (true) {
...
/* produce an item in
next_produced */
...
wait(empty);
wait(mutex);
...
Bounded Buffer Problem
(Cont.)
• The structure of the consumer process
while (true) {
wait(full);
wait(mutex);
...
/* remove an item from
buffer to next_consumed */
...
signal(mutex);
Readers-Writers Problem
• A data set is shared among a number
of concurrent processes
– Readers – only read the data set; they do
not perform any updates
– Writers – can both read and write
• Problem – allow multiple readers to
read at the same time
– Only one single writer can access the
shared data at the same time
• Several variations of how readers and
writers are considered – all involve
Readers-Writers Problem
(Cont.)
• Shared Data
– Data set
– Semaphore rw_mutex initialized to 1
– Semaphore mutex initialized to 1
– Integer read_count initialized to 0
Readers-Writers Problem
(Cont.)
• The structure of a writer process
while (true) {
wait(rw_mutex);
...
/* writing is
performed */
...
signal(rw_mutex);
}
Readers-Writers Problem
(Cont.)
• The structure of a reader process
while (true){
wait(mutex);
read_count++;
if (read_count == 1) /* first reader */
wait(rw_mutex);
signal(mutex);
...
/* reading is performed */
...
wait(mutex);
read count--;
if (read_count == 0) /* last reader */
signal(rw_mutex);
signal(mutex);
}
Readers-Writers Problem
Variations
• The solution in previous slide can
result in a situation where a writer
process never writes. It is
referred to as the “First reader-
writer” problem.
• The “Second reader-writer”
problem is a variation the first
reader-writer problem that state:
– Once a writer is ready to write, no
“newly arrived reader” is allowed to
read.
Readers/Writers Problem
• A data area is shared among many
processes
– Some processes only read the data area,
some only write to the area
• Conditions to satisfy:
1. Multiple readers may read the file at once.
2. Only one writer at a time may write
3. If a writer is writing to the file, no reader may
read it.
Readers have Priority
int readcnt=0; // current reader performs reading here
Semaphore mutex=1; wait(mutex); // a reader wants to leave
Semaphore wrt=1; readcnt--;
// Reader process : // that is, no reader is left in the critical section,
do { if (readcnt == 0)
// Reader wants to enter the critical section signal(wrt); // writers can enter
wait(mutex);
signal(mutex); // reader leaves
// The number of readers has now increased by 1
readcnt++; } while(true);
// there is atleast one reader in the critical section
// this ensure no writer can enter if there is even // Writer process :
one reader do {
// thus we give preference to readers here // writer requests for critical section
if (readcnt==1) wait(wrt);
wait(wrt); // critical section
signal(mutex); // performs the write
// leaves the critical section
// other readers can enter while this current reader signal(wrt);
is inside } while(true);
// the critical section
Dining-Philosophers Problem
• N philosophers’ sit at a round table with
a bowel of rice in the middle.
• They spend their lives alternating
thinking and eating.
• They do not interact with their
Dining-Philosophers Problem Algorithm
• Semaphore Solution
• The structure of Philosopher i:
while (true){
wait (chopstick[i] );
wait (chopStick[ (i + 1) % 5] );
/* eat for awhile */
signal (chopstick[i] );
signal (chopstick[ (i + 1) % 5] );
/* think for awhile */
• What is the problem with this
algorithm?
Monitor Solution to Dining Philosophers
monitor DiningPhilosophers
{
enum { THINKING; HUNGRY, EATING) state [5] ;
condition self [5];
void pickup (int i) {
state[i] = HUNGRY;
test(i);
if (state[i] != EATING) self[i].wait;
}
void putdown (int i) {
state[i] = THINKING;
// test left and right neighbors
test((i + 4) % 5);
test((i + 1) % 5);
}
Solution to Dining Philosophers (Cont.)
void test (int i) {
if ((state[(i + 4) % 5] != EATING) &&
(state[i] == HUNGRY) &&
(state[(i + 1) % 5] != EATING) ) {
state[i] = EATING ;
self[i].signal () ;
}
}
initialization_code() {
for (int i = 0; i < 5; i++)
state[i] = THINKING;
}
}
Solution to Dining Philosophers (Cont.)
• Each philosopher “i” invokes the
operations pickup() and putdown() in the
following sequence:
DiningPhilosophers.pickup(i);
/** EAT **/
DiningPhilosophers.putdown(i);
Some Key Terms Related to Concurrency
