Chapter 5: Process
Synchronization
Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013
Chapter 5: Process Synchronization
Background
The Critical-Section Problem
Peterson’s Solution
Synchronization Hardware
Mutex Locks
Semaphores
Classic Problems of Synchronization
Monitors
Synchronization Examples
Operating System Concepts – 9th Edition 5.2 Silberschatz, Galvin and Gagne ©2013
Objectives
To present the concept of process synchronization.
To introduce the critical-section problem, whose solutions can be used
to ensure the consistency of shared data
To present both software and hardware solutions of the critical-
section problem
To examine several classical process-synchronization problems
To explore several tools that are used to solve process
synchronization problems
Operating System Concepts – 9th Edition 5.3 Silberschatz, Galvin and Gagne ©2013
Process Synchronization
A cooperating process is one that can affect or be affected by other
processes in the system
Cooperating Process
Directly share a logical Be allowed to share
Address Data only through files
(both code and data) Or messages
Concurrent access to share data may result in data
inconsistency!
We discuss various mechanism to ensure the orderly execution
of cooperating processes that share a logical address space
So that data consistency is maintained
Operating System Concepts – 9th Edition 5.4 Silberschatz, Galvin and Gagne ©2013
Producer Consumer Problem
A producer process produces information that is consumed by a
consumer process.
For example, a compiler may produce assembly code, which is
consumed by an assembler.
The assembler, in turn, may produce object modules, which are
consumed by the loader.
One solution to the producer-consumer problem uses shared memory.
To allow producer and consumer processes to run concurrently, we must
have available a buffer of items that can be filled by the producer and
emptied by the consumer.
Operating System Concepts – 9th Edition 5.5 Silberschatz, Galvin and Gagne ©2013
Producer Consumer Problem
This buffer will reside in a region of memory that is shared by the
producer and consumer processes.
A producer can produce one item while the consumer is consuming
another item.
The producer and consumer must be synchronized, so that the
consumer does not try to consume an item that has not yet been
produced.
Operating System Concepts – 9th Edition 5.6 Silberschatz, Galvin and Gagne ©2013
Two kinds of buffers
Unbounded Buffer:
Places no practical limit on the size of the buffer.
The consumer may have to wait for new items, but
The producer can always produce new items
Bounded Buffer:
Assumes a fixed buffer size.
In this case, the consumer must wait if the buffer is empty,
and the producer must wait if the buffer is full
Operating System Concepts – 9th Edition 5.7 Silberschatz, Galvin and Gagne ©2013
Race Condition
counter variable = 0
counter is incremented every time we add a new item to the buffer
counter++
counter is decremented every time we remove one item from the buffer
counter—-
--------------------------.---------------Example----------------------------------------------
Suppose that the value of the variable counter is currently 5
The producer and consumer processes execute the statements
"counter++" and "counter--" concurrently.
Following the execution of these two statements, the value of the variable
counter may be 4, 5, or 6!
The only correct result, though, is counter == 5, which is generated
correctly if the producer and consumer execute separately.
Operating System Concepts – 9th Edition 5.8 Silberschatz, Galvin and Gagne ©2013
Race Condition
counter++ could be implemented as
register1 = counter
register1 = register1 + 1
counter = register1
counter-- could be implemented as
register2 = counter
register2 = register2 - 1
counter = register2
Consider this execution interleaving with “count = 5” initially:
S0: producer execute register1 = counter {register1 = 5}
S1: producer execute register1 = register1 + 1 {register1 = 6}
S2: consumer execute register2 = counter {register2 = 5}
S3: consumer execute register2 = register2 – 1 {register2 = 4}
S4: producer execute counter = register1 {counter = 6 }
S5: consumer execute counter = register2 {counter = 4}
Operating System Concepts – 9th Edition 5.9 Silberschatz, Galvin and Gagne ©2013
Race Condition
We would arrive at this incorrect state because we allowed both
processes to manipulate the variable counter concurrently
A situation like this, where several processes access and manipulate the
same data concurrently
and the outcome of the execution depends on the particular order
in which the access takes place, is called a race condition
Clearly, we want the resulting changes not to interface with one another
Hence, we need process synchronization
Operating System Concepts – 9th Edition 5.10 Silberschatz, Galvin and Gagne ©2013
Critical Section Problem
Consider system of n processes {p0, p1, … pn-1}
Each process has segment of code executing shared data, called
critical section in which
Process may be changing common variables, updating table, writing a
file, and so on.
When one process in critical section, no other may be in its
critical section
That is, no two processes are executing in their critical sections
at the same time.
Critical section problem is to design protocol to solve this
Each process must ask permission to enter critical section
The section of code implementing this request is the entry section
The critical section may be followed by exit section
The remaining code is the remainder section
Operating System Concepts – 9th Edition 5.11 Silberschatz, Galvin and Gagne ©2013
Critical Section
General structure of process Pi
Operating System Concepts – 9th Edition 5.12 Silberschatz, Galvin and Gagne ©2013
Algorithm for Process Pi
do {
while (turn == j);
critical section
turn = j;
remainder section
} while (true);
Operating System Concepts – 9th Edition 5.13 Silberschatz, Galvin and Gagne ©2013
Solution to 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 only those
processes that are not executing in their remainder sections can
participate in the decision on which will enter its critical section next,
and this selection cannot be postponed indefinitely (i.e. decision without
any delay).
3. Bounded Waiting - There exist a bound or limit 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 – 9th Edition 5.14 Silberschatz, Galvin and Gagne ©2013
Peterson’s Solution
A classic software-based solution to the critical-section problem
May not work correctly on modern computer architectures.
However, it provides a good algorithmic description of solving the
critical-section problem and
illustrates some of the complexities involved in designing
software that addresses the requirements of mutual exclusion,
progress, and bounded waiting requirements.
Operating System Concepts – 9th Edition 5.15 Silberschatz, Galvin and Gagne ©2013
Peterson’s Solution
Two process solution
Assume that the load and store machine-language instructions are
atomic; that is, cannot be interrupted
The two processes share two variables:
int turn;
Boolean flag[2]
The variable turn indicates whose turn it is to enter the critical
section
The flag array is used to indicate if a process is ready to enter the
critical section.
flag[i] = true implies that process Pi is ready!
Operating System Concepts – 9th Edition 5.16 Silberschatz, Galvin and Gagne ©2013
Algorithm for Process Pi, Pj
do { Pi
flag[i] = true; • ; means there is no
turn = j; statement under this loop
while (flag[j] && turn = = j); • If while condion is true ,
critical section never goes to the next
flag[i] = false; statement
remainder section • Turn variable take one
} while (true); value at a time
• Therefore, only one
process goes for critical
section
Pj
do {
flag[j] = true;
turn = i;
while (flag[i] && turn = = i);
critical section
flag[j] = false;
remainder section
} while (true);
Operating System Concepts – 9th Edition 5.17 Silberschatz, Galvin and Gagne ©2013
Peterson’s Solution (Cont.)
Provable that the three CS requirement are met:
1. Mutual exclusion is preserved
Pi enters CS only if:
either flag[j] = false or turn = i
2. Progress requirement is satisfied; i.e., two process take the
decision
3. Bounded-waiting requirement is met; because they are not
waiting indefinitely
Operating System Concepts – 9th Edition 5.18 Silberschatz, Galvin and Gagne ©2013
Hardware-based Solution: Test and Set
Lock
A hardware solution to the synchronization problem.
There is a shared lock variable which can take either of the two
values, 0 (unlock) or 1 (lock)
Before entering into the critical section, a process inquires about the
lock.
If it is locked, it keeps on waiting till it becomes free.
If it is not locked, it takes the lock and executes the critical section.
Operating System Concepts – 9th Edition 5.19 Silberschatz, Galvin and Gagne ©2013
Test and Set Lock: Atomic Operation
Single Operation
Intially, lock value is 0
Operating System Concepts – 9th Edition 5.20 Silberschatz, Galvin and Gagne ©2013
Test and Set Lock: Atomic Operation
Because some other processes (say process P3) may go to
critical section (It does not ensure P2 process must take turn
after the P1)
Operating System Concepts – 9th Edition 5.21 Silberschatz, Galvin and Gagne ©2013
Software-based solution: Semaphore
Semaphore proposed by Edger Dijkstra, is a technique to manage concurrent
processes by using a simple integer value, which is known as a semaphore.
Semaphore is simply a variable which is non-negative and shared between threads.
This variable is used to solve the critical section problem and to achieve process
synchronization in the multiprocessing environment.
Semaphore S – integer variable that is not initialized
Can only be accessed via two indivisible (atomic) operations
Where S is a semaphore/a shared integer variable
Definition of the wait() operation // when processes want to enter
critical section or use shared resources
wait(S) { // P(S)
while (S <= 0); // busy wait //if 𝑺 > 𝟎, it goes to next
S--;}
Definition of the signal() operation// process in critical section
signal(S) {
S++;}
Operating System Concepts – 9th Edition 5.22 Silberschatz, Galvin and Gagne ©2013
Software-based solution: Semaphore
All the modifications to the integer value of the semaphore in the wait 0 and signal
operations must be executed indivisibly.
That is, when one process modifies the semaphore value, no other process
can simultaneously modify that same semaphore value.
Operating System Concepts – 9th Edition 5.23 Silberschatz, Galvin and Gagne ©2013
Types of Semaphore
Binary semaphore – integer value can range only between 0 and 1
Same as a mutex (mutually exclusive) lock
0 means shard resources are being used, requesting process has to wait
1 means free, requesting process can use it
wait(S) { signal(S) {
while (S <= 0) S++;
; // busy wait }
S--;
}
Counting semaphore – integer value can range over an unrestricted domain.
It is used to control access to a resource that has multiple instances
Operating System Concepts – 9th Edition 5.24 Silberschatz, Galvin and Gagne ©2013
Disadvantages of Semaphore
The main disadvantage of the semaphore definition that was discussed is that it
requires busy waiting.
While a process is in its critical section, any other process that tries to enter its
critical section must loop continuously in the entry code.
Busy waiting wastes CPU cycles that some other process might be able to use
productively.
This type of semaphore is also called a spinlock because the process "spins"
while waiting for the lock.
Operating System Concepts – 9th Edition 5.25 Silberschatz, Galvin and Gagne ©2013
Overcome the busy waiting of
Semaphore
Modify the wait() and signal() semaphore operations
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.
The block operation places a process into a waiting queue associated with the
semaphore, and the state of the process is switched to the waiting state.
Then control is transferred to the CPU scheduler, which selects another
process to execute.
Operating System Concepts – 9th Edition 5.26 Silberschatz, Galvin and Gagne ©2013
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 – 9th Edition 5.27 Silberschatz, Galvin and Gagne ©2013
Classical Problems of Synchronization
Classical problems used to test newly-proposed synchronization
schemes
Bounded-Buffer Problem
Readers and Writers Problem
Dining-Philosophers Problem
Operating System Concepts – 9th Edition 5.28 Silberschatz, Galvin and Gagne ©2013
Classical problem of Synchronization
(Bounded-Buffer Problem)
There is a buffer of n slots and each slot is capable of storing one unit of
data.
There are two processes running, namely, Producer and Consumer,
which are operating on the buffer.
The producer tries to insert data into an empty slot of the buffer.
The consumer tries to remove data from a filled slot in the buffer.
The Producer must not insert data when the buffer is full.
The Consumer must not remove data when the buffer is empty.
The Producer and Consumer should not insert and remove data
simultaneously.
Operating System Concepts – 9th Edition 5.29 Silberschatz, Galvin and Gagne ©2013
Solution of bounded buffer using
Semaphore
m (mutex), a binary semaphore which is used to acquire and release
the lock.
empty, a counting semaphore whose initial value is the number of
slots in the buffer, since, initially all slots are empty. (initially,
empty=10, 10 is the number of slot)
full, a counting semaphore whose initial value is 0. (Initially, 0)
Operating System Concepts – 9th Edition 5.30 Silberschatz, Galvin and Gagne ©2013
Classical problem of Synchronization Readers-
Writers Problem
A database is to be shared among several concurrent processes.
Some of these processes may want only to read the database,
whereas others may want to update (that is, to read and write) the
database.
We distinguish between these two types of processes by referring to the
former as Readers and to the latter as Writers.
Obviously, if two readers access the shared data simultaneously, no
adverse affects will result.
However, if a writer and some other thread (either a reader or a
writer) access the database simultaneously, chaos may ensue.
To ensure that these difficulties do not arise, we require that the
writers have exclusive access to the shared database.
This synchronization problem is referred to as the readers-writers
problem.
Operating System Concepts – 9th Edition 5.31 Silberschatz, Galvin and Gagne ©2013
Solution to Readers-Writers Problem
We will make use of two semaphores and an integer variable:
1. mutex, a semaphore (initialized to 1) which is used to ensure
mutual exclusion where readcount is updated i.e. when any reader
enters or exit from the critical section.
2. wrt, a semaphore (initialized to 1) common to both reader and
writer processes.
3. readcount, is not semaphore, an integer variable (initialized to 0)
that keeps track of how many processes are currently reading the
object.
Operating System Concepts – 9th Edition 5.32 Silberschatz, Galvin and Gagne ©2013
Solution to Readers-Writers Problem
Mutex semaphore acquires or release lock
Operating System Concepts – 9th Edition 5.33 Silberschatz, Galvin and Gagne ©2013
Classical Problems of
Synchronization(Dining-Philosophers Problem)
§ Phiosophers represent proceess
§ Forks indicates resources
Philosophers spend their lives alternating thinking and eating
Thinking:
When a philosopher thinks, he does not interact with his colleagues
Eating:
When a philosopher gets hungry he tries to pick up the two forks that are closest to
him (left & right). A philosopher may pick up only one fork at a time.
One cannot pick up a fork that is already in the hand of a neighbor.
When a hungry philosopher has both his forks at the same time, he eats without
releasing his forks. When he has finished eating, he puts down both of his forks and
starts thinking again.
Only two philosophers who are not neighbor can eat simultaneously
Operating System Concepts – 9th Edition 5.34 Silberschatz, Galvin and Gagne ©2013
Solution of Dining-Philosophers
Problem
One simple solution is to represent each fork/chopstick with a semaphore.
A philosopher tries to grab a fork/chopstick by executing a wait () operation on
that semaphore.
He releases his fork/chopsticks by executing the signal () operation on the
appropriate semaphores.
Thus, the shared data are:
semaphore chopstick[5];
where all the elements of chopstick are initialized to 1.
(binary semaphore)
Operating System Concepts – 9th Edition 5.35 Silberschatz, Galvin and Gagne ©2013
Solution of Dining-Philosophers
Problem
Although this solution guarantees that no two neighbors are eating
simultaneously, it could still create a deadlock.
Suppose that all five philosophers become hungry simultaneously and each grabs
their left chopstick. All the elements of chopstick will now be equal to 0.
When each philosopher tries to grab his right chopstick, he will be delayed
forever.
Operating System Concepts – 9th Edition 5.36 Silberschatz, Galvin and Gagne ©2013
Possible Solution to Avoid Deadlock
Allow at most four philosophers to be sitting simultaneously at the table.
Allow a philosopher to pick up his chopstick only if both chopsticks are
available (to do this he must pick them up in a critical section).
Use an asymmetric solution; that is, an odd philosopher picks up first his left
chopstick and then his right chopstick, whereas an even philosopher picks up his
right chopstick and then his left chopstick (Deadlock/starvation).
Operating System Concepts – 9th Edition 5.37 Silberschatz, Galvin and Gagne ©2013
Monitors
A high level abstraction that provides a convenient and effective mechanism for
process synchronization.
In semaphore is not designed properly (wrongly) in one process, then dead-lock
occurs.
A monitor type presents a set of programmer-defined operations that provide
mutual exclusion within the monitor.
The monitor type also contains the declaration of variables whose values define
the state of an instance of that type, along with the bodies of procedures or
functions that operate on those variables.
Operating System Concepts – 9th Edition 5.38 Silberschatz, Galvin and Gagne ©2013
Monitors
A procedure defined within a monitor can access only those variables declared locally
within the monitor and its formal parameters.
Similarly, the local variables of a monitor can be accessed by only the local
procedures.
The monitor construct ensures that only one process at a time can be active
within the monitor.
Condition Construct- condition x, y; // for process synchronization
The only operations that can be invoked on a condition variables are wait ( )
and signal ( ).
The operation x.wait() ; means that the process invoking this operation is suspended
(waiting) until another process invokes x.signal ( ); // x is a shared variable
The x. signal ( ) operation resumes exactly one suspended process.
monitor monitor-name
{
// shared variable declarations
procedure P1 (…) { …. }
procedure Pn (…) {……}
Initialization code (…) { … }
}
}
Operating System Concepts – 9th Edition 5.39 Silberschatz, Galvin and Gagne ©2013
Monitor with Condition Variables
Operating System Concepts – 9th Edition 5.40 Silberschatz, Galvin and Gagne ©2013
Dining-Philosophers Solution Using
Monitors
We now illustrate monitor concepts by presenting a deadlock-free solution to the
dining-philosophers problem.
This solution imposes the restriction that a philosopher may pick up his
chopsticks only if both of them are available.
To code this solution, we need to distinguish among three states in which we may
find a philosopher. For this purpose, we introduce the following data structure:
enum { thinking, hungry, eating } state [5];
Philosopher i can set the variable state [i] = eating only if his two neighbors are
not
eating: (state [(i+4)% 5]!= eating) and (state [(i+1)% 5] != eating).
We also need to declare condition self [5]; where philosopher i can delay
himself when he is hungry but is unable to obtain the chopsticks he needs
Operating System Concepts – 9th Edition 5.41 Silberschatz, Galvin and Gagne ©2013
Dining-Philosophers Solution Using
Monitors
Operating System Concepts – 9th Edition 5.42 Silberschatz, Galvin and Gagne ©2013
Dining-Philosophers Solution Using
Monitors
https://www.youtube.com/watch?v=WIj06NCxkWE&list=PLBlnK6fEyqRiVhbXDGL
XDk_OQAeuVcp2O&index=67
https://www.youtube.com/watch?v=_yl0qAnsa_8&list=PLBlnK6fEyqRiVhbXDGLXD
k_OQAeuVcp2O&index=68
https://www.youtube.com/watch?v=A41_0uRnb2A&list=PLBlnK6fEyqRiVhbXDGLX
Dk_OQAeuVcp2O&index=69
https://www.youtube.com/watch?v=fWL8HAIrgMw&list=PLBlnK6fEyqRiVhbXDGLX
Dk_OQAeuVcp2O&index=70
https://www.youtube.com/watch?v=LlnBI2yjvlg&list=PLBlnK6fEyqRiVhbXDGLXDk
_OQAeuVcp2O&index=71
Operating System Concepts – 9th Edition 5.43 Silberschatz, Galvin and Gagne ©2013
Thank You
Operating System Concepts – 9th Edition 5.44 Silberschatz, Galvin and Gagne ©2013
End of Chapter 5
Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013
