Process Synchronization

• Background
• The Critical-Section Problem
• Synchronization Hardware
• Semaphores
• Classical Problems of Synchronization
• Critical Regions
• Monitors
• Synchronization in Solaris 2 & Windows 2000
 Background
• Concurrent access to shared data may result in data
inconsistency.
• Maintaining data consistency requires mechanisms to
ensure the orderly execution of cooperating processes.
• Shared-memory solution to bounded-buffer problem
allows at most n – 1 items in buffer at the same time.
A solution, where all N buffers are used is not simple.
– Suppose that we modify the producer-consumer code by
adding a variable counter, initialized to 0 and incremented
each time a new item is added to the buffer
Processes
1.Serial
2.Parallel
Parallel Process

Independent Interdependent
(cooperative)

Process Synchronization
• P1 • P2
{.. {..
….. …..
….. …..
….. …..
count++ count--
….. …..
….. …..
….. …..
} }

count – shared variable

• P3 • P4
{.. {..
….. …..
….. …..
….. …..
write file1 read file1
….. …..
….. …..
….. …..
} }

file1 – shared variable

• P5 • P6
{.. {..
….. …..
….. …..
….. …..
read read
….. …..
….. DB1 …..
….. …..
} }
 Bounded-Buffer

• Shared data

#define BUFFER_SIZE 10
typedef struct {
...
} item;
item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;
int counter = 0;
 Bounded-Buffer
• Producer process

item nextProduced;

while (1) {
while (counter == BUFFER_SIZE)
; /* do nothing */
buffer[in] = nextProduced;
in = (in + 1) % BUFFER_SIZE;
counter++;
}
 Bounded-Buffer
• Consumer process

item nextConsumed;

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

counter++;
counter--;

must be performed atomically.

• Atomic operation means an operation that

completes in its entirety without interruption.
 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
 Bounded Buffer
• 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.
 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.
 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.
 The 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
Requirements for avoiding Race Conditions
• No two processes may be simultaneously
inside their Critical Region
• No Assumptions may be made about the
speed or the number of CPUs
• No process running outside its critical region
may block other processes
• No Process should have to wait forever to
enter its critical region
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.
 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.
 Algorithm 1
• Shared variables:
– int turn;
initially turn = 0
– turn - i  Pi can enter its critical section
• Process Pi
do {
while (turn != i) ;
critical section
turn = j;
reminder section
} while (1);
• Satisfies mutual exclusion, but not progress
 Algorithm 2
• Shared variables
– boolean flag[2];
initially flag [0] = flag [1] = false.
– flag [i] = true  Pi ready to enter its critical section
• Process Pi
do {
flag[i] := true;
while (flag[j]) ;
critical section
flag [i] = false;
remainder section
} while (1);
• Satisfies mutual exclusion, but not progress requirement.
 Algorithm 3
• Combined shared variables of algorithms 1 and 2.
• Process Pi
do {
flag [i]:= true;
turn = j;
while (flag [j] and turn = j) ;
critical section
flag [i] = false;
remainder section
} while (1);
• Meets all three requirements; solves the critical-
section problem for two processes.
 Peterson’s Solution
Enter_CS(int process) P0 P1
{
int other; 0 1
other = 1- process; interested F F
interested[process]=TRUE;
turn=process; turn 0
while (turn==process && interested[other]==TRUE);
// Wait for CS() access;
Access CS();
}
Leave_CS( int process)
{
interested[process]=FALSE
}
 Synchronization Hardware
Many systems provide hardware support for
implementing the critical section code.
All these solutions are based on idea of locking
Protecting critical regions via locks
Uniprocessors – could disable interrupts
Currently running code would execute without preemption
Generally too inefficient on multiprocessor systems
Operating systems using this not broadly scalable
Modern machines provide special atomic hardware
instructions
Atomic = non-interruptible
Either test memory word and set value
Or swap contents of two memory words
Solution to Critical-section Problem Using Locks
do {
acquire lock
critical section
release lock
remainder section
} while (TRUE);
 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
 acquire() and release()
acquire() {
while (!available); /* busy wait */
available = false;;
}
release() {
available = true;
}

do {
acquire lock
critical section
release lock
remainder section
} while (true);
 Semaphores
• Synchronization tool that does not require busy waiting.
• Semaphore S – integer variable
• can only be accessed via two standard atomic operations
• The operations were originally termed P (for wait from
Dutch proberen to test) and V(for signal from verhogen to
increment)
wait (S):
while S 0 do no-op;
S--;

signal (S):
S++;
 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);
 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
• Consider P1 and P2 that require S1 to happen before S2
• Create a semaphore “synch” initialized to 0
P1:
S1;
signal(synch);
P2:
wait(synch);
S2;
• Can implement a counting semaphore S as a binary semaphore
 Semaphore Implementation
• 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
• Could now have busy waiting in critical section
implementation
• But implementation code is short
• Little busy waiting if critical section rarely occupied
• Note that applications may spend lots of time in
critical sections and therefore this is not a good
solution
Semaphore Implementation with no Busy waiting
With each semaphore there is an associated waiting queue
Each entry in a waiting queue has two data items:
 value (of type integer)
 pointer to next record in the list
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++;
if (S->value <= 0) {
remove a process P from S->list;
wakeup(P);
}
}
 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
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
• Buffers size n,
• 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_consumed
*/
...
signal(mutex);
signal(empty);
...
/* consume the item in next consumed */
...
} while (true);
 Readers-Writers Problem
A datadase 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 some form of priorities
Shared Data
Database
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

do {
wait(rw_mutex);
...
/* writing is performed */
...
signal(rw_mutex);
} 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

• Philosophers spend their lives alternating thinking and eating

• Don’t interact with their neighbors, occasionally try to pick up 2 chopsticks
(one at a time) to eat from bowl
• Need both to eat, then release both when done
• In the case of 5 philosophers
• Shared data
• Bowl of rice (data set)
• Semaphore chopstick [5] initialized to 1
 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.
 Problems with Semaphores

Incorrect use of semaphore operations:

signal (mutex) …. wait (mutex)

wait (mutex) … wait (mutex)

Omitting of wait (mutex) or signal (mutex)

(or both)

• Deadlock and starvation are possible.

 Monitors
• A high-level abstraction that provides a convenient and effective mechanism for
process synchronization
• Abstract data type, internal variables only accessible by code within the
procedure
• Only one process may be active within the monitor at a time
• But not powerful enough to model some synchronization schemes

monitor monitor-name
{
// shared variable declarations
procedure P1 (…) { …. }

procedure Pn (…) {……}

Initialization code (…) { … }

}
}
Schematic view of a Monitor
 Condition Variables
condition x, y;

Two operations are allowed on a condition

variable:
x.wait() – a process that invokes the
operation is suspended until x.signal()
x.signal() – resumes one of processes (if
any) that invoked x.wait()
Monitor with Condition Variables
 Condition Variables Choices
If process P invokes x.signal(), and process Q is
suspended in x.wait(), what should happen
next?
Both Q and P cannot execute in parallel. If Q is
resumed, then P must wait
Options include
Signal and wait – P waits until Q either leaves the
monitor or it waits for another condition
Signal and continue – Q waits until P either leaves
the monitor or it waits for another condition
Both have pros and cons – language implementer
can decide
 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);

No deadlock, but starvation is possible

Monitor Implementation Using Semaphores
Variables

semaphore mutex; // (initially = 1)

semaphore next; // (initially = 0)
int next_count = 0;
Each 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 – Condition Variables
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 (Cont.)

The operation x.signal can be implemented as:

if (x_count > 0) {
next_count++;
signal(x_sem);
wait(next);
next_count--;
}
 Solaris 2 Synchronization
• Implements a variety of locks to support multitasking,
multithreading (including real-time threads), and
multiprocessing.

• Uses adaptive mutexes for efficiency when protecting

data from short code segments.

• Uses condition variables and readers-writers locks

when longer sections of code need access to data.

• Uses turnstiles to order the list of threads waiting to

acquire either an adaptive mutex or reader-writer lock.
 Windows 2000 Synchronization
• Uses interrupt masks to protect access to global
resources on uniprocessor systems.

• Uses spinlocks on multiprocessor systems.

• Also provides dispatcher objects which may act as

wither mutexes and semaphores.

• Dispatcher objects may also provide events. An

event acts much like a condition variable.