Process Synchronization

 A coperating process is one that can effect other

processes or effected by other processes.
 Coperating processes share a common address
space.
 Concurrent accesss to shared data causes data
inconsistency.
 For example a producer will be producing to a
buffer and a consumer will always consuming
from a buffer.
 The buffer has a limited size.
Concurrent access to shared data may result in
data inconsistency.
Maintaining data consistency requires
mechanisms to ensure the orderly execution of
cooperating processes.
 Bounded-Buffer
 Shared data

#define BUFFER_SIZE 10
typedef struct {
...
} item;
item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;
int counter = 0;

Operating System Concepts 7.2 Silberschatz, Galvin and Gagne 2002

 Bounded-Buffer

 Producer process

item nextProduced;

while (1) {
while (counter == BUFFER_SIZE)
; /* do nothing */
buffer[in] = nextProduced;
in = (in + 1) % BUFFER_SIZE;
counter++;
}

Operating System Concepts 7.3 Silberschatz, Galvin and Gagne 2002

 Bounded-Buffer

 Consumer process

item nextConsumed;

while (1) {
while (counter == 0)
; /* do nothing */
nextConsumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
}

Operating System Concepts 7.4 Silberschatz, Galvin and Gagne 2002

 Bounded Buffer

 The statements

counter++;
counter--;

must be performed atomically.

 Atomic operation means an operation that

completes in its entirety without interruption.

Operating System Concepts 7.5 Silberschatz, Galvin and Gagne 2002

 Bounded Buffer
 The statement “count++” may be implemented in
machine language as:

register1 = counter
register1 = register1 + 1
counter = register1

 The statement “count—” may be implemented as:

register2 = counter
register2 = register2 – 1
counter = register2

 If both the producer and consumer attempt to

update the buffer concurrently, the assembly
language statements may get interleaved.
 Interleaving depends upon how the producer and
consumer processes are scheduled.
Operating System Concepts 7.6 Silberschatz, Galvin and Gagne 2002
 Bounded Buffer

 Assume counter is initially 5. One interleaving

of statements is:

producer: register1 = counter (register1 = 5)

producer: register1 = register1 + 1 (register1 =
6)
consumer: register2 = counter (register2 = 5)
consumer: register2 = register2 – 1 (register2
= 4)
producer: counter = register1 (counter = 6)
consumer: counter = register2 (counter = 4)

 The value of count may be either 4 or 6, where

the correct result should be 5.

Operating System Concepts 7.7 Silberschatz, Galvin and Gagne 2002

 Race Condition

 Race condition: The situation where several

processes access – and manipulate shared
data concurrently. The final value of the
shared data depends upon which process
finishes last.

 To prevent race conditions, concurrent

processes must be synchronized.

 A job of OS for executing the the coperating

processes in an order to retain data
consistency is call as ‘process
synchronization’.

Operating System Concepts 7.8 Silberschatz, Galvin and Gagne 2002

 The Critical-Section Problem

 A coperating process is having a common

code in which it shares and changes common
variables and data . That part of the code is
called as Critical section.
(or)
Each process has a code segment, called
critical section, in which the shared data is
accessed.
 n processes all competing to use some shared
data.
 Problem –for synchronization ensure that
when one process is executing in its critical
section, no other process is allowed to
execute in its critical section.
 Each and every process should get permission
to entry into critical section.
Operating System Concepts Silberschatz, Galvin and Gagne 2002
 When it exits critical 7.9section, it starts
 Solution to Critical-Section
Problem
There are 3 solutions for critical section problem.

1. Mutual Exclusion. If process Pi is executing in

its critical section, then no other processes
can be executing in their critical sections.
2. Progress. If no process is executing in its
critical section and there exist some
processes that wish to enter their critical
section, then the processes which are
executing in their reminder sections should
wait.
3. Bounded Waiting. A bound must exist on the
number of times that other processes are
allowed to enter their critical sections after a
process has made a request to enter its
critical section and before that request is
granted.
Operating System Concepts 7.10 Silberschatz, Galvin and Gagne 2002
 Initial Attempts to Solve Problem

 Only 2 processes, P0 and P1

 General structure of process Pi (other process
Pj)
do {
entry section
critical section
exit section
reminder section
} while (1);
 Processes may share some common variables
to synchronize their actions.

Operating System Concepts 7.11 Silberschatz, Galvin and Gagne 2002

  Peterson solution is a software solution for
critical section problem.
 Peterson’s solution needs two data items to
be shared between 2 processes.

int turn;
Boolean flag[2];

Turn is initially 0. flag[0]=FALSE, flag[1]=FALSE

 The flag array is used to indicate if a process
is ready to enter into critical section.
 If flag[i] is true then it means pi is ready to
enter in its critical section.
 Before any process pi enters into critical
section , it sets the flag[i] to be true.
 At the same time Pj also may be trying to
make the flag value to j.

Operating System Concepts 7.12 Silberschatz, Galvin and Gagne 2002

 PETERSON’S SOLUTION

Operating System Concepts 7.13 Silberschatz, Galvin and Gagne 2002

 Synchronization Hardware
• We can have a hardware based solution for
critical section problem.

• Here we require a simple tool called ‘lock’.

A critical section is protected by locks.

• A process should acquire a lock before it

enters into its critical section.

• When the process exits the critical section

it releases the lock.

• Test And Set can be used in uni processor

environment.
Operating System Concepts 7.14 Silberschatz, Galvin and Gagne 2002
 Mutual Exclusion with Test-and-
Set
boolean TestAndSet(boolean &target)
{
boolean rv = target;
target = true;
return rv;
}

initially boolean lock = false;

Process Pi
do {
while (TestAndSet(lock)) ;
critical section
lock = false;
remainder section
}
Operating System Concepts 7.15 Silberschatz, Galvin and Gagne 2002
 Mutual Exclusion with Swap
Atomically swaps two variables.
void Swap(boolean &a, boolean &b) {
boolean temp = a;
a = b;
b = temp;
}

 Shared data key=true, lock=false.

Process Pi
do {
key = true;
while (key == true)
Swap(lock,key);
critical section
lock = false;
remainder section
}

Operating System Concepts 7.16 Silberschatz, Galvin and Gagne 2002

 Semaphores
 A semaphore is a software solution for the critical
section problem.
 It is an integer variable and can be accessed through
two operations
Signal and wait. Both are atomic operations.
 All modifications should be done to S only through wait
and signal. If one process is modifying a semaphore
value the other process cannot access it.

Wait(s)
{ while(s<=0); no-operation
s--;
}
Signal(s)
{
s++; }

Operating System Concepts 7.17 Silberschatz, Galvin and Gagne 2002

 Critical Section of n Processes

 Shared data:
semaphore mutex; //initially mutex = 1

 Process Pi:

do {
wait(mutex);

critical section

signal(mutex);

remainder section

} while (1);

Operating System Concepts 7.18 Silberschatz, Galvin and Gagne 2002

  Another example, where two concurrent
processes running their instructions
S1,S2 in P1 and P2 respectively.
 We need S2 has to be executed only
after S1 is executed.
 P1,P2 share a common semaphore
sync=0;(initialise)

S1; P1
Signal(sync);

Wait(sync); P2
S2;
Operating System Concepts 7.19 Silberschatz, Galvin and Gagne 2002
 Semaphore Implementation

 Define a semaphore as a record

typedef struct {
int value;
struct process *L;
} semaphore S;

 Assume two simple operations:

 block suspends the process that invokes it.
 wakeup(P) resumes the execution of a blocked
process P.

Operating System Concepts 7.20 Silberschatz, Galvin and Gagne 2002

 Implementation

 Semaphore operations now defined as

wait(S):
S.value--;
if (S.value <= 0) {
add this
process to S.L;
block;
}

signal(S):
S.value++;
if (S.value > 0) {
remove a
process P from S.L;
wakeup(P);
}

Operating System Concepts 7.21 Silberschatz, Galvin and Gagne 2002

 Deadlock and Starvation

 Deadlock – two or more processes are waiting

indefinitely for an event that can be caused by only
one of the waiting processes.
 Let S and Q be two semaphores initialized to 1
P0 P1
wait(S); wait(Q);
wait(Q); wait(S);
 
signal(S); signal(Q);
signal(Q) signal(S);
 Starvation – indefinite blocking. A process may
never be removed from the semaphore queue in
which it is suspended.

Operating System Concepts 7.22 Silberschatz, Galvin and Gagne 2002

 Two Types of Semaphores

 Counting semaphore – integer value can

range over an unrestricted domain.
 Binary semaphore – integer value can range
only between 0 and 1; can be simpler to
implement.

Operating System Concepts 7.23 Silberschatz, Galvin and Gagne 2002

 Classical Problems of
Synchronization
 Bounded-Buffer Problem

 Readers and Writers Problem

 Dining-Philosophers Problem

Operating System Concepts 7.24 Silberschatz, Galvin and Gagne 2002

 Bounded-Buffer Problem
No producer is producing while other is updating the
buffer, in the same manner a consumer should be
prevented to access the buffer while one is consuming.
And we have to ensure that a consumer can consume
only after producer is produced, when no items are ther
in the buffer.

Shared data

semaphore full, empty, mutex;

Initially:

full = 0, empty = n, mutex = 1

Operating System Concepts 7.25 Silberschatz, Galvin and Gagne 2002

 Bounded-Buffer Problem Producer
Process
PRODUCER CONSUMER

do { do {
… wait(full);
wait(empty);

wait(mutex); wait(mutex);
…
add next item to …
remove an
item
uffer from
… buffer
signal(mutex);
…
signal(full);
signal(mutex);
} while (1);
Operating System Concepts 7.26 signal(empty);…
Silberschatz, Galvin and Gagne 2002
 Readers-Writers Problem

A number of readers read the database and a

number of writers will write the database.
1. When writer access the database all the
readers and writers are kept waiting.
2. When the reader is reading the database ,a
writer should be given a chance even several
readers are waiting.
 Shared data

semaphore mutex, wrt;

Initially

mutex = 1, wrt = 1, readcount = 0

Operating System Concepts 7.27 Silberschatz, Galvin and Gagne 2002

 Readers-Writers Problem Writer
Process

wait(wrt);
…
writing is performed
…
signal(wrt);

Operating System Concepts 7.28 Silberschatz, Galvin and Gagne 2002

 Readers-Writers Problem Reader
Process

wait(mutex);
readcount++;
if (readcount == 1)
wait(wrt);
signal(mutex);
…
reading is performed
…
wait(mutex);
readcount--;
if (readcount == 0)
signal(wrt);
signal(mutex):
Operating System Concepts 7.29 Silberschatz, Galvin and Gagne 2002
 Dining-Philosophers Problem
Consider 5 philosophers
spend their time in living
and thinking. When a
philosopher thinks, he doe
not interact with anybody,
but when he feels hungry,
he takes both the
chopsticks and starts
eating. He cannot picku
the chopsticks if they are
in the data
 Shared hands of his
neighbours.
semaphore chopstick[5];
Initially all values are 1

Operating System Concepts 7.30 Silberschatz, Galvin and Gagne 2002

 Dining-Philosophers Problem
 Philosopher i:
do {
wait(chopstick[i])
wait(chopstick[(i+1) % 5])
…
eat
…
signal(chopstick[i]);
signal(chopstick[(i+1) % 5]);
…
think
…
} while (1);
Operating System Concepts 7.31 Silberschatz, Galvin and Gagne 2002
 Critical Regions

 High-level synchronization construct

 A shared variable v of type T, is declared as:
v: shared T
 Variable v accessed only inside statement
region v do
begin
---------;
-----------;
end
While statement are being executed,
no other process can access variable v.

Operating System Concepts 7.32 Silberschatz, Galvin and Gagne 2002

 All critical regions that are ‘tagged’ with the
same variable have compiler-enforced mutual
exclusion so that only one of them can be
executed at a time: Process B:

Process A: region V1 do
region V1 do begin
begin { Do other stuff. }
{ Do some stuff. } end;
end;

region V2 do
begin
{ Do more stuff. }
end;
Here process A can be executing inside its V2 region while process
B is executing inside its V1 region, but if they both want to execute
inside their respective V1 regions only one will be permitted to
proceed. Each shared variable (V1 and V2 above) has a queue
associated with it. Once one process is executing code inside a
region tagged with a shared variable, any other processes that
attempt to enter a region tagged with the same variable are
blocked
Operating Systemand put in the queue. 7.33
Concepts Silberschatz, Galvin and Gagne 2002
 Conditional Critical Regions Critical regions :

They aren’t equivalent to semaphores. As described so far,

they lack condition synchronization. We can use
semaphores to put a process to sleep until some condition
is met (e.g. see the bounded-buffer Producer-Consumer
problem), but we can’t do this with critical regions.
Conditional critical regions provide condition
synchronization for critical regions:
region v when B
do
begin ...

end;
where B is a boolean expression (usually B will refer to
v). Conditional critical regions work as follows: 1. A
process wanting to enter a region for v must obtain the
mutex lock. If it cannot, then it is queued. 2. Once the
lock is obtained the boolean expression B is tested. If B
evaluates to true then the process proceeds, otherwise it
Operating System Concepts 7.34 Silberschatz, Galvin and Gagne 2002
 Example – Bounded Buffer

 Shared data:

struct buffer {
int pool[n];
int count, in, out;
}

Operating System Concepts 7.35 Silberschatz, Galvin and Gagne 2002

 Bounded Buffer Producer Process

 Producer process inserts nextp into the

shared buffer

region buffer when( count < n) {

pool[in] = nextp;
in:= (in+1) % n;
count++;
}

Operating System Concepts 7.36 Silberschatz, Galvin and Gagne 2002

 Bounded Buffer Consumer
Process
 Consumer process removes an item from the
shared buffer and puts it in nextc

region buffer when (count > 0) {

nextc = pool[out];
out = (out+1) % n;
count--;
}

Operating System Concepts 7.37 Silberschatz, Galvin and Gagne 2002

 Monitors
 High-level synchronization construct or a structure
that allows the safe sharing of an abstract data
type or a resource among concurrent processes.

monitor monitor-name
{
shared variable declarations
procedure body P1 (…) {
...
}
procedure body P2 (…) {
...
}
procedure body Pn (…) {
...
}
{
initialization code
}
Operating System Concepts
} 7.38 Silberschatz, Galvin and Gagne 2002
 Monitors

 To allow a process to wait within the

monitor, a condition variable must be
declared, as
condition x, y;
 Condition variable can only be used with the
operations wait and signal.
 The operation
x.wait();
means that the process invoking this
operation is suspended until another process
invokes
x.signal();
 The x.signal operation resumes exactly one
suspended process. If no process is
suspended, then the signal operation has no
effect.

Operating System Concepts 7.39 Silberschatz, Galvin and Gagne 2002

 Schematic View of a Monitor

Operating System Concepts 7.40 Silberschatz, Galvin and Gagne 2002

 Monitor With Condition Variables

Operating System Concepts 7.41 Silberschatz, Galvin and Gagne 2002

Implementation of Monitors
Monitor ResourceAllocator
{ InitializationCode()
Boolean busy; {
Condition x; busy=TRUE;
Void acquire(int time) }
{
If (busy) ResourceAllocator R;
x.wait(time);
busy=TRUE; R.Acquire(t);
} ………….
void release() Access the resource
{ …………..
busy=FALSE; R.Release()
x.signal();
}

Operating System Concepts 7.42 Silberschatz, Galvin and Gagne 2002

 • Wait operations is used to make a process
sleep if the resource is not available.

• Signal operation is used to wakeup one

process to avail the resource.

• These two functions are called using a

condition variable.

• When several processes requesting a

resource, the process that has shortest
time allocation period Is allocated for
request.

Operating System Concepts 7.43 Silberschatz, Galvin and Gagne 2002

 END

Operating System Concepts 7.44 Silberschatz, Galvin and Gagne 2002