CHAPTER 4:

PROCESS
SYNCHRONIZATION
CHAPTER 4: PROCESS SYNCHRONIZATION
□ Background
□ The Critical-Section Problem
□ Semaphores - Usage, Implementation
□ Classic Problems of Synchronization
The bounded buffer problem, The
reader writer problem
The dining philosopher problem
 BACKGROUND

□ A Cooperating process is one that can affect or

be affected by other processes executing in the
system.
□ Cooperating processes can either directly share a
logical address space (i.e. both code and data) or
be allowed to share data only through files or
messages.
□ The former case is achieved through the use of
light weight processes or threads.
□ Concurrent access to shared data may
result in data inconsistency.
 Shared=5,6 ,4 Uniprocessor
Shared=5

P1 P2

X=shared X=5 Y=shared Y=5

X++ X=6 Y-- Y=4

Sleep(1) Sleep(1)

Shared=X Shared=Y

P1 –P2
 CRITICAL SECTION PROBLEM
□ Consider system consisting of n processes {p0, p1, … pn-1}
□ Each process has a segment of code called a critical section in
which process may be changing common variables, updating
table, writing file, etc.
□ The important feature of the system is that when one process is
executing in its critical section, no other process is to be allowed
to execute in its critical section.
□ That is no two processes are executing in their critical section
at the same time.
□ Critical section problem is to design protocol that the processes
can use to cooperate.
□ Each process must ask permission to enter its critical section. The
section of code implementing this request is the entry section
□ The critical section may be followed by an exit section.
□ The remaining code is the remainder section
CRITICAL SECTION

□ General structure of process Pi

ALGORITHM FOR PROCESS PI

do {

while (turn == j);

critical section
turn = j;

remainde
r section
} while (true);
 SOLUTION/CONDITION /CRITERIA TO
CRITICAL-SECTION PROBLEM
Critical Section is a part of the program where shared resources are accessed by the
various process
Solution to the critical Section problem must satisfy the following requirements.
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 all the requesting
processes except the one which are in its remainder can participate in the
decision on which will enter the critical section
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.
4. No Assumption related to H/W speed

Note : The processes which are in their remainder section are the one that have
recently finished with their critical section. The processes again should not be
immediately given the chance to enter their critical section
 SEMAPHORE
□
Semaphore is introduced by Dijkstra in 1965
□ It is a synchronization tool used to deal with the critical
section on the mutual exclusion.
□ It is guaranteed that once a semaphore operation
has started , no other process can access the
semaphore until the operation has completed or
blocked.
Application of semaphores
1) To solve critical section problem
2) To decide order of execution among process
3) Resource management
4) Managing concurrent processes by use of a
integer value(variable)
SEMAPHORE
□ Dijkstra proposed having two operation :
Down : This operation decrements the value of the
semaphore addressed if it is greater than zero.
Up : This operation increments the value of the
semaphore addressed.
□ A semaphore consists of two primitive operations
□ wait() Originally called P(S) or also called
sleep,down
□ signal() Originally called V(S) or also called
wake-up,up
Semaphore S is an integer variable that is initialized
to some value and it is accessed by two standard
atomic operations wait() and signal()
SEMAPHORE
□ Definition of the wait() operation
wait(S)
{
while (S <= 0); // busy wait
S--;
}
□ Definition of the signal() operation
signal(S)
{
S++;
}

P1,p2
S=1,0,1,0
 SEMAPHORE USAGE
□ do{
waiting(s);
// critical section
signal(s)
// remainder
section
} while(TRUE);

wait(S)
{
while (S <= 0); // busy wait
S--;
}
SEMAPHORE USAGE
□ Counting semaphores can be used to control access to a given
resource consisting a finite number of instances.
□ The semaphore is initialized to the no. of resources available.
□ Each process that wishes to use a resource performs a wait()
operation on the semaphore (thereby decrementing the count).
□ When a process release a resource, it performs a
signal() operation incrementing the count.
□ When count for the semaphores goes to 0 all resources are being
used. After that processes that wish to use a resource will block
until the count becomes greater than 0.
SEMAPHORE USAGE
□ We can also use semaphore to solve various synchronization problems
□ E.g. Consider two concurrently running processes: P1 with a statement S1
and P2 with a statement S2. Suppose we require that S2 be executed only
after S1 has completed. We can implement this scheme readily by letting P1
and P2 share common semaphore synch initialized to 0 and by inserting the
statement
P1:
S1;
signal(synch);
P2:
wait(sync
h); S2;
□ Because synch is initialized to 0, P2 will execute S2 only after P1 has invoked
signal(synch) which is after statement S1 has been executed.
SEMAPHORE IMPLEMENTATION
□ In multiprogramming environment only one CPU is shared among process.
□ A process which is waiting utilizes the CPU only to execute the wait loop.
Which is nothing but wastage of CPU cycles. This is called as problem of
busy waiting.
□ This type of semaphores is called spinlock because the process spins while
waiting for the lock.
□ To overcome the need for busy waiting , we can modify the definition of the
wait(). And signal() semaphore operation.
□ When a process executes the wait() operation and finds that the
semaphore value is not positive it must wait. However rather than
engaging in busy waiting the process can block itself.
□ i.e. A Process which is waiting is blocked and added to list of blocked
processes. (blocked process is process that is waiting for some event
to occur).
□ A process which is blocked by operation P, will be restarted by wakeup
operation. Wakeup operation is included in operation V / signal.
SEMAPHORE IMPLEMENTATION
□ Each semaphores has an integer value and a list of processes list.
□ When a process wait on a semaphore, it is added to the list of process.

□ A signal() operation removes one process from the list of waiting process and
awakens that process.
□ Two operations:

□ block – place the process invoking the operation on the

appropriate waiting queue
□ wakeup – remove one of processes in the waiting queue and place it
in the ready queue
□ typedef
struct{ int
value;
struct process
*list;
} semaphore;
 IMPLEMENTATION WITH NO BUSY WAITING (CONT.)

wait(semaphore *S) {
S->value--;
if (S->value <=0) {
add this process
to S->list;
block();
}
}
signal(semaphore *S) {
S->value++;
remove a process P
from S->list;
wakeup(P);
}
SEMAPHORE IMPLEMENTATION
□ block() operation suspends the process that invokes it.
□ The wakeup(P) operation resumes the execution of a blocked process P.
□ The list of processes that are blocked, waiting on a semaphore S, can
be easily implemented by a link field in each PCB.
□ Each semaphore contains an integer value and a pointer to the list of
PCB. A FIFO queue is used to remove process from the list. No two
processes can execute wait and signal operations on the same
semaphores at the same time.
□ This situation can be resolved in two ways.
1) In a uniprocessor environment while execution time of wait and signal
operations, interrupts can simple be inhibited. As only currently running
process executes, until interrupt are reentered
2) In multiprogramming environment inhibility interrupts will not work
Command from different processes may be interleaved in some arbitrary way.
 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
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
□ It is used to illustrate the power of synchronization.
□ mutex semaphore provide mutual exclusion.
□ Empty and full semaphores count no. of empty and full
buffers respectively
□ n buffers, 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

do {
...
/* produce an item in next_produced */
...
wait(empty);
wait(mutex);
...
/* add next produced
to the buffer */
...
signal(mutex);
signal(full);
} while (true);
 BOUNDED BUFFER PROBLEM
(CONT.)
□ The structure of the consumer process

Do
{ wait(full
);
wait(mutex);
...
/* remove an
item from
buffer to
next_cons
umed */
...
signal(mutex);
signal(empty);
...
/* consume the
item in
next
 READERS-WRITERS PROBLEM
□ The simultaneous access to a file by more than one process at a
time must have some control over it.
□ E.g. while one process is reading a file , any other process
should be allowed to read the same file.
□ If any process is writing to the file , no other process should
be allowed to read as well as write to the file.
□ Such control can be achieved using semaphore.
□ Mutex and wrt are common semaphore shared by all processes
and initialized to one.
□ Readcount is a common integer initialized to zero, it keeps
count of concurrent reader processes.
□ i.e mutex=1

□ wrt=1

□ Readcount=0
READERS-WRITERS PROBLEM (CONT.)
□ The structure of a reader process

do {
wait(mutex);
readcount++;
if (readcount ==
1)
wait(wrt);
signal(mutex);
...
/* reading
is performed */
...
wait(mutex);
readcount--;
if (readcount
== 0)
signal(wrt);
signal(mutex);
} while (true);
 READERS-WRITERS PROBLEM (CONT.)

□ The structure of a writer process

do {
wait(wrt);
...
/* writing is performed */
...
signal(wrt);
} while (true);
 READERS-WRITERS PROBLEM
□ Case 1: More than one processes are reading
□ We start with mutex=1 and wrt=1 and readcount=0.
□ Suppose A is a process that want to read.
□ Process A will execute following steps.
1) wait(mutex) will make mutex value 0
2) Readcount++ readcount=1 i.e. one process is
reading.
3) if (readcount == 1) wait(wrt); i.e. wrt=0
4) Signal(mutex) will make mutex=1
5) Reading of process A will begin. Now some other process B
also want to read then it will also execute some set of steps
 READERS-WRITERS PROBLEM
1) wait(mutex) will make mutex value 0
2) Readcount++ readcount=1 i.e. one process is
reading.
3) if (readcount == 1) wait(wrt); i.e. wrt=0
4) Signal(mutex) will make mutex=1
5) Reading of process B start
Such any number of processes can read
simultaneously After each of it finish reading executes
following steps
wait(mutex);

readcount--;
if (readcount ==
0)
signal(wrt);
signal(mutex);
 READERS-WRITERS PROBLEM
□ Case 2: Process A reading and process B trying to write.
□ Process A will execute reader structure by which mutex and wrt will be set
to 0 and readcount will set to 1 and process A will start reading. Now while
process A is reading, if process B try to write process B will execute
following steps.

wait(mutex);
readcount++;
if (readcount == 1)
wait(wrt);
Process B cannot proceed because wrt is made 0 by process A therefore
process B is blocked.
 READERS-WRITERS PROBLEM
□ Case 3: Process A writing and process B also trying to
write.
We
□ start wrt=1

Process A will execute following steps.

1) wait(wrt); wrt is made 0
2) Writing started
Suppose process B also want to write it will execute following steps.
1) wait(wrt)
Process B is blocked because wrt value is made 0 by process
A.
 READERS-WRITERS PROBLEM
□ Case 4: Process A writing and process B trying to read.
□ We start wrt=1, mutex=1
readcount=0 Process A will execute
following steps.
1) wait(wrt); wrt is made 0
2) Writing started
Suppose
1) process B will execute
wait(mutex)
2)following steps.
Readcount++
3) if
(readcount
== 1)
w
a
i
t
(
w
r
t
 READERS-WRITERS PROBLEM (CONT.)

□ The structure of a writer process

do {
wait(wrt);
...
/* writing is
performed */
...
signal(wrt);
} while (true);
 READERS-WRITERS PROBLEM (CONT.)
□ The structure of a reader process
do {
wait(mutex);
read_count++;
if
(read_count
== 1)
wait(rw_mutex);
signal(mutex);
...
/* reading
is performed */
...
wait(mutex);
read count--;
if (read_count
== 0)
signal(rw_mutex);
signal(mutex);
} while (true);
 DINING-PHILOSOPHERS PROBLEM
1. Consider five philosopher who spend their
lives thinking and eating.
2. The philosopher share a circular table surrounded
by five chairs, each belonging to one philosopher
3. In the center of the table is a bowl of rice and
the table is laid with five single chopsticks.

4. When a philosopher thinks he does not interact

with their colleagues.
5. From time to time a philosopher get hungry and tries to pick up the
two chopsticks that are closest to them
6. A philosopher may pick up only one chopstick at a time. He cannot pick
chopstick that is already in the hand of a neighbour .
7. When a hungry philosopher has both chopsticks at the same time, he
eats.
 DINING-PHILOSOPHERS PROBLEM
8. When he finished eating he puts down both the chopsticks and
starts thinking
9. It is representation of the need to allocate several resources in a
deadlock free and starvation free manner
10. Solution is to represent chopstick with semaphores
11. A semaphore tries to grab a chopsticks by executing s wait() operation.
 DINING-PHILOSOPHERS PROBLEM
ALGORITHM
□ The structure of Philosopher i:
do {
wait (chopstick[i] );
wait (chopStick[ (i + 1) % 5] );

// eat signal

(chopstick[i] );
signal
(chopstick[ (i + 1) % 5] );

//

think

} while (TRUE);
□ What is the problem with this
algorithm?
DINING-PHILOSOPHERS PROBLEM ALGORITHM
(CONT.)

□ Deadlock handling
□ Allow at most 4 philosophers to be sitting
simultaneously at the table.
□ Allow a philosopher to pick up the forks only if
both are available (picking must be done in a critical
section.
□ Use an asymmetric solution -- an odd-numbered
philosopher picks up first the left chopstick and then the right
chopstick. Even-numbered philosopher picks up first the
right chopstick and then the left chopstick.
END OF CHAPTER 5