Chapter 6: Process

Synchronization

Operating System Concepts 8th Edition,

Silberschatz, Galvin and Gagne 2009

Module 6: Process Synchronization

Background
The Critical-Section Problem
Petersons Solution
Synchronization Hardware
Semaphores

Classic Problems of Synchronization

Monitors
Synchronization Examples
Atomic Transactions

Operating System Concepts 8th Edition

6.2

Silberschatz, Galvin and Gagne 2009

Objectives
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 introduce the concept of an atomic transaction and describe mechanisms

to ensure atomicity

Operating System Concepts 8th Edition

6.3

Silberschatz, Galvin and Gagne 2009

Background
Concurrent access to shared data may result in data

inconsistency

Maintaining data consistency requires mechanisms to

ensure the orderly execution of cooperating processes

Suppose that we wanted to provide a solution to the

consumer-producer problem that fills all the buffers. We

can do so by having an integer count that keeps track of
the number of full buffers. Initially, count is set to 0. It is
incremented by the producer after it produces a new
buffer and is decremented by the consumer after it
consumes a buffer.

Operating System Concepts 8th Edition

6.4

Silberschatz, Galvin and Gagne 2009

Race Condition

count++ could be implemented as

register1 = count
register1 = register1 + 1
count = register1

count-- could be implemented as

register2 = count
register2 = register2 - 1
count = register2

Consider this execution interleaving with count = 5 initially:

S0: producer execute register1 = count {register1 = 5}

S1: producer execute register1 = register1 + 1 {register1 = 6}
S2: consumer execute register2 = count {register2 = 5}
S3: consumer execute register2 = register2 - 1 {register2 = 4}
S4: producer execute count = register1 {count = 6 }
S5: consumer execute count = register2 {count = 4}

Operating System Concepts 8th Edition

6.5

Silberschatz, Galvin and Gagne 2009

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 8th Edition

6.6

Silberschatz, Galvin and Gagne 2009

Petersons Solution
Two process solution
Assume that the LOAD and STORE 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 8th Edition

6.7

Silberschatz, Galvin and Gagne 2009

Algorithm for Process Pi

do {
flag[i] = TRUE;
turn = j;
while (flag[j] && turn == j);
critical section
flag[i] = FALSE;
remainder section
} while (TRUE);

Operating System Concepts 8th Edition

6.8

Silberschatz, Galvin and Gagne 2009

Semaphore

Synchronization tool that does not require busy waiting

Semaphore S integer variable

Two standard operations modify S: wait() and signal()

Originally called P() and V()

Less complicated

Can only be accessed via two indivisible (atomic) operations

wait (S) {
while S <= 0
; // no-op
S--;
}

signal (S) {
S++;
}

Operating System Concepts 8th Edition

6.9

Silberschatz, Galvin and Gagne 2009

Semaphore as General Synchronization Tool

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

Also known as mutex locks

Can implement a counting semaphore S as a binary semaphore

Provides mutual exclusion

Semaphore mutex;

// initialized to 1

do {
wait (mutex);
// Critical Section
signal (mutex);
// remainder section
} while (TRUE);

Operating System Concepts 8th Edition

6.10

Silberschatz, Galvin and Gagne 2009

Semaphore Implementation
Must guarantee that no two processes can execute wait () and signal ()

on the same semaphore at the same time

Thus, implementation becomes the critical section problem where the

wait and signal code are placed in the crtical 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.

Operating System Concepts 8th Edition

6.11

Silberschatz, Galvin and Gagne 2009

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.

Operating System Concepts 8th Edition

6.12

Silberschatz, Galvin and Gagne 2009

Semaphore Implementation with no Busy waiting (Cont.)

Implementation of wait:
wait(semaphore *S) {
S->value--;
if (S->value < 0) {
add this process to S->list;
block();
}
}
Implementation of signal:
signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
remove a process P from S->list;
wakeup(P);
}
}

Operating System Concepts 8th Edition

6.13

Silberschatz, Galvin and Gagne 2009

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

Priority Inversion - Scheduling problem when lower-priority process holds a

lock needed by higher-priority process

Operating System Concepts 8th Edition

6.14

Silberschatz, Galvin and Gagne 2009

Classical Problems of Synchronization

Bounded-Buffer Problem
Readers and Writers Problem
Dining-Philosophers Problem

Operating System Concepts 8th Edition

6.15

Silberschatz, Galvin and Gagne 2009

Bounded-Buffer Problem
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.

Operating System Concepts 8th Edition

6.16

Silberschatz, Galvin and Gagne 2009

Bounded Buffer Problem (Cont.)

The structure of the producer process

do {
// produce an item in nextp
wait (empty);
wait (mutex);
// add the item to the buffer
signal (mutex);
signal (full);
} while (TRUE);

Operating System Concepts 8th Edition

6.17

Silberschatz, Galvin and Gagne 2009

Bounded Buffer Problem (Cont.)

The structure of the consumer process

do {
wait (full);
wait (mutex);
// remove an item from buffer to nextc
signal (mutex);
signal (empty);
// consume the item in nextc
} while (TRUE);

Operating System Concepts 8th Edition

6.18

Silberschatz, Galvin and Gagne 2009

Readers-Writers Problem
A data set 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

Shared Data

Data set

Semaphore mutex initialized to 1

Semaphore wrt initialized to 1

Integer readcount initialized to 0

Operating System Concepts 8th Edition

6.19

Silberschatz, Galvin and Gagne 2009

Readers-Writers Problem (Cont.)

The structure of a writer process

do {
wait (wrt) ;
//

writing is performed

signal (wrt) ;
} while (TRUE);

Operating System Concepts 8th Edition

6.20

Silberschatz, Galvin and Gagne 2009

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);

Operating System Concepts 8th Edition

6.21

Silberschatz, Galvin and Gagne 2009

Dining-Philosophers Problem

Shared data

Bowl of rice (data set)

Semaphore chopstick [5] initialized to 1

Operating System Concepts 8th Edition

6.22

Silberschatz, Galvin and Gagne 2009

Dining-Philosophers Problem (Cont.)

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);

Operating System Concepts 8th Edition

6.23

Silberschatz, Galvin and Gagne 2009

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)

Operating System Concepts 8th Edition

6.24

Silberschatz, Galvin and Gagne 2009

Monitors

A high-level abstraction that provides a convenient and effective

mechanism for process synchronization

Only one process may be active within the monitor at a time

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

procedure Pn () {}
Initialization code ( .) { }

}
}

Operating System Concepts 8th Edition

6.25

Silberschatz, Galvin and Gagne 2009

Schematic view of a Monitor

Operating System Concepts 8th Edition

6.26

Silberschatz, Galvin and Gagne 2009

Condition Variables
condition x, y;
Two operations on a condition variable:

x.wait () a process that invokes the operation is

suspended.

x.signal () resumes one of processes (if any) that

invoked x.wait ()

Operating System Concepts 8th Edition

6.27

Silberschatz, Galvin and Gagne 2009

Monitor with Condition Variables

Operating System Concepts 8th Edition

6.28

Silberschatz, Galvin and Gagne 2009

Monitor Implementation Using Semaphores

Variables

Each procedure F will be replaced by

semaphore mutex; // (initially = 1)

semaphore next; // (initially = 0)
int next-count = 0;

wait(mutex);

body of F;

if (next_count > 0)
signal(next)
else
signal(mutex);

Mutual exclusion within a monitor is ensured.

Operating System Concepts 8th Edition

6.29

Silberschatz, Galvin and Gagne 2009

Monitor Implementation

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--;

Operating System Concepts 8th Edition

6.30

Silberschatz, Galvin and Gagne 2009

Monitor Implementation
The operation x.signal can be implemented as:

if (x-count > 0) {
next_count++;
signal(x_sem);
wait(next);
next_count--;
}

Operating System Concepts 8th Edition

6.31

Silberschatz, Galvin and Gagne 2009

Synchronization Examples
Solaris
Windows XP
Linux
Pthreads

Operating System Concepts 8th Edition

6.32

Silberschatz, Galvin and Gagne 2009

Solaris 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

Operating System Concepts 8th Edition

6.33

Silberschatz, Galvin and Gagne 2009

Windows XP 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 either mutexes and

semaphores

Dispatcher objects may also provide events

An event acts much like a condition variable

Operating System Concepts 8th Edition

6.34

Silberschatz, Galvin and Gagne 2009

Linux Synchronization
Linux:

Prior to kernel Version 2.6, disables interrupts to implement short critical

sections

Version 2.6 and later, fully preemptive

Linux provides:

semaphores

spin locks

Operating System Concepts 8th Edition

6.35

Silberschatz, Galvin and Gagne 2009

Pthreads Synchronization
Pthreads API is OS-independent
It provides:

mutex locks

condition variables

Non-portable extensions include:

read-write locks

spin locks

Operating System Concepts 8th Edition

6.36

Silberschatz, Galvin and Gagne 2009

Atomic Transactions
System Model
Log-based Recovery
Checkpoints
Concurrent Atomic Transactions

Operating System Concepts 8th Edition

6.37

Silberschatz, Galvin and Gagne 2009

System Model
Assures that operations happen as a single logical unit of work, in its

entirety, or not at all

Related to field of database systems

Challenge is assuring atomicity despite computer system failures
Transaction - collection of instructions or operations that performs

single logical function

Here we are concerned with changes to stable storage disk

Transaction is series of read and write operations

Terminated by commit (transaction successful) or abort

(transaction failed) operation

Aborted transaction must be rolled back to undo any changes it

performed

Operating System Concepts 8th Edition

6.38

Silberschatz, Galvin and Gagne 2009

Types of Storage Media

Volatile storage information stored here does not survive system

crashes

Example: main memory, cache

Nonvolatile storage Information usually survives crashes

Example: disk and tape

Stable storage Information never lost

Not actually possible, so approximated via replication or RAID to

devices with independent failure modes

Goal is to assure transaction atomicity where failures cause loss of

information on volatile storage

Operating System Concepts 8th Edition

6.39

Silberschatz, Galvin and Gagne 2009

Log-Based Recovery
Record to stable storage information about all modifications by a transaction
Most common is write-ahead logging

Log on stable storage, each log record describes single transaction write
operation, including

Transaction name

Data item name

Old value

New value

<Ti starts> written to log when transaction Ti starts

<Ti commits> written when Ti commits

Log entry must reach stable storage before operation on data

occurs

Operating System Concepts 8th Edition

6.40

Silberschatz, Galvin and Gagne 2009

Log-Based Recovery Algorithm

Using the log, system can handle any volatile memory errors

Undo(Ti) restores value of all data updated by Ti

Redo(Ti) sets values of all data in transaction Ti to new values

Undo(Ti) and redo(Ti) must be idempotent

Multiple executions must have the same result as one execution

If system fails, restore state of all updated data via log

If log contains <Ti starts> without <Ti commits>, undo(Ti)

If log contains <Ti starts> and <Ti commits>, redo(Ti)

Operating System Concepts 8th Edition

6.41

Silberschatz, Galvin and Gagne 2009

Checkpoints

Log could become long, and recovery could take long

Checkpoints shorten log and recovery time.

Checkpoint scheme:

1.

Output all log records currently in volatile storage to stable storage

2.

Output all modified data from volatile to stable storage

3.

Output a log record <checkpoint> to the log on stable storage

Now recovery only includes Ti, such that Ti started executing before the
most recent checkpoint, and all transactions after Ti All other transactions
already on stable storage

Operating System Concepts 8th Edition

6.42

Silberschatz, Galvin and Gagne 2009

Concurrent Transactions
Must be equivalent to serial execution serializability
Could perform all transactions in critical section

Inefficient, too restrictive

Concurrency-control algorithms provide serializability

Operating System Concepts 8th Edition

6.43

Silberschatz, Galvin and Gagne 2009

Serializability
Consider two data items A and B
Consider Transactions T0 and T1
Execute T0, T1 atomically
Execution sequence called schedule
Atomically executed transaction order called serial schedule
For N transactions, there are N! valid serial schedules

Operating System Concepts 8th Edition

6.44

Silberschatz, Galvin and Gagne 2009

Schedule 1: T0 then T1

Operating System Concepts 8th Edition

6.45

Silberschatz, Galvin and Gagne 2009

Nonserial Schedule
Nonserial schedule allows overlapped execute

Resulting execution not necessarily incorrect

Consider schedule S, operations Oi, Oj

Conflict if access same data item, with at least one write

If Oi, Oj consecutive and operations of different transactions & Oi and Oj

dont conflict

Then S with swapped order Oj Oi equivalent to S

If S can become S via swapping nonconflicting operations

S is conflict serializable

Operating System Concepts 8th Edition

6.46

Silberschatz, Galvin and Gagne 2009

Schedule 2: Concurrent Serializable Schedule

Operating System Concepts 8th Edition

6.47

Silberschatz, Galvin and Gagne 2009

Locking Protocol
Ensure serializability by associating lock with each data item

Follow locking protocol for access control

Locks

Shared Ti has shared-mode lock (S) on item Q, Ti can read Q but not
write Q

Exclusive Ti has exclusive-mode lock (X) on Q, Ti can read and write

Q

Require every transaction on item Q acquire appropriate lock

If lock already held, new request may have to wait

Similar to readers-writers algorithm

Operating System Concepts 8th Edition

6.48

Silberschatz, Galvin and Gagne 2009

Two-phase Locking Protocol

Generally ensures conflict serializability
Each transaction issues lock and unlock requests in two phases

Growing obtaining locks

Shrinking releasing locks

Does not prevent deadlock

Operating System Concepts 8th Edition

6.49

Silberschatz, Galvin and Gagne 2009

Timestamp-based Protocols
Select order among transactions in advance timestamp-ordering
Transaction Ti associated with timestamp TS(Ti) before Ti starts

TS(Ti) < TS(Tj) if Ti entered system before Tj

TS can be generated from system clock or as logical counter

incremented at each entry of transaction

Timestamps determine serializability order

If TS(Ti) < TS(Tj), system must ensure produced schedule equivalent to

serial schedule where Ti appears before Tj

Operating System Concepts 8th Edition

6.50

Silberschatz, Galvin and Gagne 2009

Timestamp-based Protocol Implementation

Data item Q gets two timestamps

W-timestamp(Q) largest timestamp of any transaction that executed

write(Q) successfully

R-timestamp(Q) largest timestamp of successful read(Q)

Updated whenever read(Q) or write(Q) executed

Timestamp-ordering protocol assures any conflicting read and write

executed in timestamp order

Suppose Ti executes read(Q)

If TS(Ti) < W-timestamp(Q), Ti needs to read value of Q that was

already overwritten

read operation rejected and Ti rolled back

If TS(Ti) W-timestamp(Q)

read executed, R-timestamp(Q) set to max(R-timestamp(Q), TS(Ti))

Operating System Concepts 8th Edition

6.51

Silberschatz, Galvin and Gagne 2009

Timestamp-ordering Protocol
Suppose Ti executes write(Q)

If TS(Ti) < R-timestamp(Q), value Q produced by Ti was needed

previously and Ti assumed it would never be produced

If TS(Ti) < W-tiimestamp(Q), Ti attempting to write obsolete value of Q

Write operation rejected, Ti rolled back

Write operation rejected and Ti rolled back

Otherwise, write executed

Any rolled back transaction Ti is assigned new timestamp and restarted

Algorithm ensures conflict serializability and freedom from deadlock

Operating System Concepts 8th Edition

6.52

Silberschatz, Galvin and Gagne 2009

Schedule Possible Under Timestamp Protocol

Operating System Concepts 8th Edition

6.53

Silberschatz, Galvin and Gagne 2009

End of Chapter 6

Operating System Concepts 8th Edition,

Silberschatz, Galvin and Gagne 2009