Operating Systems

Module 3
Process Synchronization
 Outline
Interprocess Communication
Race condition
Critical Section
Semaphores
 Interprocess Communication
 Processes within a system may be independent or cooperating
 Cooperating process can affect or be affected by other processes,
including sharing data
 Reasons for cooperating processes:
 Information sharing
 Computation speedup
 Modularity
 Convenience
 Cooperating processes need interprocess communication (IPC)
 Two models of IPC
 Shared memory
 Message passing

Operating System Concepts – 9th Edition 3.3 Silberschatz, Galvin and Gagne ©2013
 Communications Models
(a) Message passing. (b) shared memory.

Operating System Concepts – 9th Edition 3.4 Silberschatz, Galvin and Gagne ©2013
 Interprocess Communication – Shared Memory

 An area of memory shared among the processes that wish to communicate

 The communication is under the control of the users processes not the
operating system.
 Major issues is to provide mechanism that will allow the user processes to
synchronize their actions when they access shared memory.
 Message system – processes communicate with each other without
resorting to shared variables
 IPC facility provides two operations:
 send(message)
 receive(message)

 The message size is either fixed or variable

Operating System Concepts – 9th Edition 3.5 Silberschatz, Galvin and Gagne ©2013
 Critical section

Operating System Concepts – 9th Edition 3.6 Silberschatz, Galvin and Gagne ©2013
 Critical section

Operating System Concepts – 9th Edition 3.7 Silberschatz, Galvin and Gagne ©2013
 Critical section

Operating System Concepts – 9th Edition 3.8 Silberschatz, Galvin and Gagne ©2013
Operating System Concepts – 9th Edition 3.9 Silberschatz, Galvin and Gagne ©2013
Operating System Concepts – 9th Edition 3.10 Silberschatz, Galvin and Gagne ©2013
 Critical Section Problem

 Consider system of n processes {p0, p1, … pn-1}

 Each process has critical section segment of code
 Process may be changing common variables, updating table,
writing file, etc
 When one process in critical section, no other may be in its
critical section
 Critical section problem is to design protocol to solve this
 Each process must ask permission to enter critical section in
entry section, may follow critical section with exit section, then
remainder section

Operating System Concepts – 9th Edition 3.11 Silberschatz, Galvin and Gagne ©2013
 Critical Section

 General structure of process Pi

Operating System Concepts – 9th Edition 3.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 3.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 the selection
of the processes that will enter the critical section next cannot be
postponed indefinitely
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
 Assume that each process executes at a nonzero speed
 No assumption concerning relative speed of the n processes

Operating System Concepts – 9th Edition 3.14 Silberschatz, Galvin and Gagne ©2013
 Peterson’s Solution

 Good algorithmic description of solving the problem

 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 3.15 Silberschatz, Galvin and Gagne ©2013
 Algorithm for Process Pi

Operating System Concepts – 9th Edition 3.16 Silberschatz, Galvin and Gagne ©2013
Operating System Concepts – 9th Edition 3.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
3. Bounded-waiting requirement is met

Operating System Concepts – 9th Edition 3.18 Silberschatz, Galvin and Gagne ©2013
 Bakery Algorithm in Process Synchronization

 The Bakery algorithm, by Leslie Lamport, is one of the simplest known

solutions to the mutual exclusion problem for the general case of N
process (N>2).
 Bakery Algorithm is a critical section solution for N processes. The
algorithm preserves the first come first serve property.
 Before entering its critical section, the process receives a number.
Holder of the smallest number enters the critical section.
 If processes Pi and Pj receive the some number,

Operating System Concepts – 9th Edition 8.19 Silberschatz, Galvin and Gagne ©2013
 Bakery Algorithm in Process Synchronization

 Notation – lexicographical order (ticket #, process id #) – Firstly the ticket

number is compared. If same then the process ID is compared next, ie,
– (a, b) < (c, d) if a < c or if a = c and b < d
– max(a [0], . . ., a [n-1]) is a number, k, such that k >= a[i] for i = 0, . . ., n – 1

Shared data – choosing is an array [0..n – 1] of boolean values; & number is an

array [0..n – 1] of integer values. Both are initialized to False & Zero respectively.

Operating System Concepts – 9th Edition 8.20 Silberschatz, Galvin and Gagne ©2013
 Bakery Algorithm in Process Synchronization

lock(i);

critical section

unlock(i);

Remainder section

Operating System Concepts – 9th Edition 8.21 Silberschatz, Galvin and Gagne ©2013
 Bakery Algorithm in Process Synchronization

Operating System Concepts – 9th Edition 8.22 Silberschatz, Galvin and Gagne ©2013
 Bakery Algorithm in Process Synchronization

Operating System Concepts – 9th Edition 8.23 Silberschatz, Galvin and Gagne ©2013
Operating System Concepts – 9th Edition 8.24 Silberschatz, Galvin and Gagne ©2013
Operating System Concepts – 9th Edition 8.25 Silberschatz, Galvin and Gagne ©2013
Operating System Concepts – 9th Edition 8.26 Silberschatz, Galvin and Gagne ©2013
 Bakery Algorithm

Operating System Concepts – 9th Edition 8.27 Silberschatz, Galvin and Gagne ©2013
 Bakery Algorithm

 Firstly the process sets its “choosing” variable to be TRUE indicating its
intent to enter critical section.
 Then it gets assigned the highest ticket number corresponding to other
processes. Then the “choosing” variable is set to FALSE indicating that it
now has a new ticket number. This is in-fact the most important and
confusing part of the algorithm. It is actually a small critical section in itself
!
 The very purpose of the first three lines is that if a process is modifying its
TICKET value then at that time some other process should not be allowed
to check its old ticket value which is now obsolete. This is why inside the
for loop before checking ticket value we first make sure that all other
processes have the “choosing” variable as FALSE.
 After that we proceed to check the ticket values of processes where
process with least ticket number/process id gets inside the critical section.
 The exit section just resets the ticket value to zero.

Operating System Concepts – 9th Edition 8.28 Silberschatz, Galvin and Gagne ©2013
 Bakery Algorithm

Critical section for n processes

 Before entering its critical section, process receives a number.
Holder of the smallest number enters the critical section.
 If processes Pi and Pj receive the same number, if i < j, then Pi is
served first; else Pj is served first.
 The numbering scheme always generates numbers in increasing
order of enumeration; i.e., 1,2,3,3,3,3,4,5...

Operating System Concepts – 9th Edition 8.29 Silberschatz, Galvin and Gagne ©2013
 Bakery Algorithm

 Notation < lexicographical order (ticket #, process id #)

 (a,b) < c,d) if a < c or if a = c and b < d
 max (a0,…, an-1) is a number, k, such that k  ai for i - 0,
…, n – 1
 Shared data
boolean choosing[n];
int number[n];
Data structures are initialized to false and 0 respectively

Operating System Concepts – 9th Edition 8.30 Silberschatz, Galvin and Gagne ©2013
 Bakery Algorithm

do {
choosing[i] = true;
number[i] = max(number[0], number[1], …, number [n – 1])+1;
choosing[i] = false;
for (j = 0; j < n; j++) {
while (choosing[j]) ;
while ((number[j] != 0) && (number[j,j] < number[i,i])) ;
}
critical section
number[i] = 0;
remainder section
} while (1);

Operating System Concepts – 9th Edition 8.31 Silberschatz, Galvin and Gagne ©2013
 Mutex Locks

 OS designers build software tools to solve critical section problem

 Simplest is mutex lock
 Protect a critical section by first acquire() a lock then release() the
lock
 Boolean variable indicating if lock is available or not
 Calls to acquire() and release() must be atomic
Usually implemented via hardware atomic instructions

 But this solution requires busy waiting
 This lock therefore called a spinlock

Operating System Concepts – 9th Edition 8.32 Silberschatz, Galvin and Gagne ©2013
 Lock Variable

 Software solution implemented in user

mode
 N>2
 Entry section = acquire()
 Exit section = release()
 No guarantee of mutual exclusion

Operating System Concepts – 9th Edition 8.33 Silberschatz, Galvin and Gagne ©2013
 Synchronization Hardware

 Test and modify the content of a word atomically

 while(test_and_set(&lock));
CS
lock = FALSE;

 Boolean test_and_set(Boolean *target){

boolean r = *target;
*target = TRUE;
return r;
}

 Mutual Exclusion and progress is achieved.

.
Operating System Concepts – 9th Edition 8.34 Silberschatz, Galvin and Gagne ©2013
 Mutual Exclusion with Test-and-Set

 Shared data:
boolean lock = false;

 Process Pi
do {
while (TestAndSet(lock)) ;
critical section
lock = false;
remainder section
}

Operating System Concepts – 9th Edition 8.35 Silberschatz, Galvin and Gagne ©2013
 Synchronization Hardware

 Atomically swap two variables.

void Swap(boolean &a, boolean &b) {

boolean temp = a;
a = b;
b = temp;
}

Operating System Concepts – 9th Edition 8.36 Silberschatz, Galvin and Gagne ©2013
 Mutual Exclusion with Swap

 Shared data (initialized to false):

boolean lock;
boolean waiting[n];

 Process Pi
do {
key = true;
while (key == true)
Swap(lock,key);
critical section
lock = false;
remainder section
Operating System Concepts – 9th Edition
} 8.37 Silberschatz, Galvin and Gagne ©2013
 Semaphore
 Synchronization tool that provides more sophisticated ways (than Mutex locks) for process
to synchronize their activities.
 Semaphore S – integer variable
 Can only be accessed via two indivisible (atomic) operations
 wait() and signal()
 Originally called P() and V()

 Definition of the wait() operation

wait(S)
{
while (S <= 0)
; // busy wait
S--;
}
 Definition of the signal() operation
signal(S)
{
S++;
}
Operating System Concepts – 9th Edition 8.38 Silberschatz, Galvin and Gagne ©2013
 Semaphore Usage

 Counting semaphore – integer value can range over an unrestricted domain

 Binary semaphore – integer value can range only between 0 and 1

 Same as a mutex lock

 Can solve various synchronization problems

 Must guarantee that no two processes can execute the wait() and signal() on the
same semaphore at the same time

 Thus, the implementation becomes the critical section problem where the wait and
signal code are placed in the critical section

Operating System Concepts – 9th Edition 8.39 Silberschatz, Galvin and Gagne ©2013
 Classical Problems of Synchronization

 Bounded-Buffer Problem

 Readers and Writers Problem

 Dining-Philosophers Problem

Operating System
Operating System Concepts – 9th Edition 8.40 Silberschatz, Galvin and Gagne ©2013
 Bounded-Buffer Problem

 Shared data
N=8
Counting semaphore full – no. of filled slots A

Counting semaphore empty – no. of empty slots B

Binary semaphore mutex C

 Initially: E

full = 0, empty = N, mutex = 1

Operating System Concepts – 9th Edition 8.41 Silberschatz, Galvin and Gagne ©2013
 Bounded-Buffer Problem
Producer Process Consumer Process
do { do {
… wait(full);
produce an item in nextp wait(mutex);
… …
wait(empty); //remove an item from buffer to nextc
wait(mutex); nextc = Buffer[OUT];
… OUT = (OUT+1) % N
//add nextp to buffer …
Buffer[IN] = nextp; signal(mutex);
IN = (IN+1) % N signal(empty);
… …
signal(mutex); //consume the item in nextc
signal(full); …
} while (1); } while (1);
Operating System Concepts – 9th Edition 8.42 Silberschatz, Galvin and Gagne ©2013
 Readers-Writers Problem

 Shared data

semaphore mutex, wrt;

Initially

mutex = 1, wrt = 1,
int readcount = 0

Operating System Concepts – 9th Edition 8.43 Silberschatz, Galvin and Gagne ©2013
 Readers-Writers Problem Reader Process
semaphore mutex = 1;
semaphore wrt = 1;
int readcount = 0;

void Reader(){
void Writer(){
wait(mutex);
wait(wrt);
readcount++;
if (readcount == 1) …
wait(wrt); writing is performed
signal(mutex); …
… signal(wrt);
reading is performed }
…
wait(mutex);
readcount--;
if (readcount == 0)
signal(wrt);
signal(mutex);
}
Operating System Concepts – 9th Edition 8.44 Silberschatz, Galvin and Gagne ©2013
 Dining-Philosophers Problem

 Shared data
semaphore chopstick[5];
Initially all values are 1
Operating System Concepts – 9th Edition 8.45 Silberschatz, Galvin and Gagne ©2013
 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 – 9th Edition 8.46 Silberschatz, Galvin and Gagne ©2013
Classical synchronization problems
Producer consumer problem
Producer consumer problem
Producer consumer problem
Producer consumer problem
Producer consumer problem
Dining philosophers problem
Dining-Philosophers Problem
Dining-Philosophers Problem
Dining-Philosophers Problem
Dining-Philosophers Problem
Dining-Philosophers Problem
Dining-Philosophers Problem
Dining-Philosophers Problem
Monitors Operating
System
Concepts
 High-level synchronization construct that allows the safe sharing of an
abstract data type among concurrent processes.
monitor monitor-name
{
shared variable declarations
procedure body P1 (…) {
...
}
procedure body P2 (…) {
...
}
procedure body Pn (…) {
...
}
{
initialization code
}
}
Monitors Operating
System
Concepts

 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.
 Schematic View of a Monitor
Queues
associated with
x, y conditions
Monitor With Condition Variables
 Dining Philosophers Example void pickup(int i) {
Operating
System
Concepts
monitor dp
state[i] = hungry;
{ test[i];
enum {thinking, hungry, eating} state[5]; if (state[i] != eating)
condition self[5]; self[i].wait();
void pickup(int i) }
void putdown(int i)
void test(int i) void putdown(int i) {
void init() { state[i] = thinking;
// test left and right neighbors
for (int i = 0; i < 5; i++)
test((i+4) % 5);
state[i] = thinking; test((i+1) % 5);
} }
} void test(int i) {
if ( (state[(I + 4) % 5] != eating) &&
(state[i] == hungry) &&
(state[(i + 1) % 5] != eating)) {
state[i] = eating;
self[i].signal();
}
}
Monitor Implementation Using Semaphores
Operating
System
Concepts
 Variables
semaphore mutex; // (initially = 1)
semaphore next; // (initially = 0)
int next-count = 0;
 Each external procedure F will be replaced by
wait(mutex);
…
body of F;
…
if (next-count > 0)
signal(next)
else
signal(mutex);
 Mutual exclusion within a monitor is ensured.
Monitor Implementation Operating
System
Concepts

 For each condition variable x, we have:

semaphore x-sem; // (initially = 0)
int x-count = 0;

 The operation x.wait can be implemented as:

x-count++;
if (next-count > 0)
signal(next);
else
signal(mutex);
wait(x-sem);
x-count--;
Monitor Implementation Operating
System
Concepts

 The operation x.signal can be implemented as:

if (x-count > 0) {
next-count++;
signal(x-sem);
wait(next);
next-count--;
}
Monitor Implementation Operating
System
Concepts
 Conditional-wait construct: x.wait(c);
 c – integer expression evaluated when the wait operation is
executed.
 value of c (a priority number) stored with the name of the process
that is suspended.
 when x.signal is executed, process with smallest associated priority
number is resumed next.
 Check two conditions to establish correctness of system:
 User processes must always make their calls on the monitor in a
correct sequence.
 Must ensure that an uncooperative process does not ignore the
mutual-exclusion gateway provided by the monitor, and try to access
the shared resource directly, without using the access protocols.
 References 71

1. Abraham Silberschatz, Peter B. Galvin, Greg Gagne-Operating

System Concepts, Wiley (2018).
2. Ramez Elmasri, A.Gil Carrick, David Levine, Operating
Systems, A Spiral Approach - McGrawHill Higher Education
(2010).
3. https://pdos.csail.mit.edu/6.828/2012/lec/l-lockfree.txt
4. https://en.wikipedia.org/wiki/Non-blocking_algorithm
RR solution
Gantt chart