Lecture Operating systems: A concept-based approach (2/e): Chapter 9 - Dhananjay M. Dhamdhere

Chapter 9 - Process synchronization. This chapter discusses the synchronization requirements of some classic problems in process synchronization and discusses how they can be met by using synchronization features such as semaphores and monitors provided in programming languages and operating systems.

in any form or by any means, without the prior written permission of the publisher, or used beyond the limited distribution to teachers and educators permitted by McGraw­Hill 

Process Synchronization

• Processes that work toward a common goal must

coordinate their activities

– Such coordination is achieved through synchronization

– We discuss two kinds of synchronization defined in Chapter 3

– Non-interacting processes are independent processes

Critical Section (CS)

• Definition

– A critical section (CS) for a data item ds is a section of code that cannot be executed concurrently with itself or with another

critical section for ds

a code segment (see next slide)

• Data access synchronization

– Is defined as ensuring an absence of race conditions over a

shared data item ds

* It is achieved by enclosing all uses of d s within critical sections

A process having critical sections

We assume a process to consist of a single infinite loop; a dashed

rectangular box depicts a critical section

(a) A process having many critical sections

(b) A process having a single critical section

Use of CS in airline reservation

to avoid race conditions

• nextseatno is examined and incremented within a CS

• Hence a race condition does not exist

Essential properties of a CS implementation

• A CS implementation must posses three properties

– Correctness

* At most one process can be in a CS for a data item d s at any time

– Progress

* When no process is in a CS for d s, a process wishing to enter a CS

progress

– Bounded wait

* If P i wishes to use a CS for d s, the number of times another process

constant

Busy wait

• A CS can be implemented as follows:

while { some process is in a CS for d s }

{ do nothing }

{ CS }

• It causes a busy wait

– Definition: Busy wait is a situation in which a process checks a condition over and over again until the condition is satisfied

– A busy wait wastes CPU power

Busy wait

• A busy wait

– May lead to priority inversion

* A low priority process is scheduled and gets into a CS for d s

Avoiding priority inversion

• The Priority inheritance protocol

– A low priority process holding a resource (or CS) inherits priority

of the highest priority process that is waiting for the resource (or CS)

(or CS) and release it

Control Synchronization

• Processes should perform actions in a desired order

– This order depends on logic of the application, e.g., in the

satellite data logging example, a record received from a satellite

is to be written into a disk file via a buffer

after another process has written a record into the buffer

process has copied the previous record out of the buffer

Control Synchronization

• Processes should perform actions in a desired order

– e.g., Process Pi should perform action ai after another process Pj has performed action aj

* Block process P i before performing action a j if P i has not yet

• We need a signaling arrangement for this

– (no connection with signals in processes)

– Next slide shows an arrangement using boolean variables

– Q: If variables are used for signaling, could race conditions arise

on these variables?

An attempt at signaling through boolean variables

Race condition in process synchronization

• A race condition exists in this program

preempted before it can set pi_blocked to true

process P

• Q: Can the race condition have another consequence?

Indivisible operation

• An indivisible operation on a set of data items {ds}

– is an operation that cannot be executed concurrently with any

other operation involving a data item included in {ds}

– To avoid the race condition of previous slide, we define two

indivisible operations

* Check_aj: If action_aj_performed is false, it sets pi_blocked to true

* Post_aj: (Q: What actions should it perform?)

Control synchronization by signaling using

indivisible operations

• Code of these actions is shown in the next slide

Indivisible operations for signaling

• check_aj either sets pi_blocked

any actions

• post_aj either changes pi_blocked

to false and activates process P i,

or sets action_aj_blocked

Implementing a critical section or indivisible

operation using a lock variable

• The process checks the boolean variable lock repeatedly until

it can enter the critical section

• The actions of checking the value of lock and setting it to closed

should be performed in an indivisible manner; it avoids a race

condition on lock

CS using Test-and-set (TS) instruction

– Check the value of LOCK and set condition code to indicate whether it is ‘open’ or ‘closed’

– Set LOCK to ‘closed’

• The BC instruction checks the condition code set by TS

CS or indivisible operation using Swap instruction

• TEMP is initialized to the value ‘closed’

• The SWAP instruction swaps LOCK and TEMP

• The COMP instruction checks the old value of LOCK and decides whether the process may enter CS

Classic process synchronization problems

• Why study these problems?

– These problems represent frequently encountered situations in process synchronization

discuss how they can be implemented

– A ‘good’ solution to a process synchronization problem must

have three properties

Classic process synchronization problems

• Three classic problems

– Producers and consumers

consumers consume the information items from the buffers

rates

– Readers and writers

– Dining philosophers

Producers and consumers

• A producer produces an item of information and writes it into

an ‘empty’ buffer; this action makes the buffer ‘full’

• A consumer copies an item of information out of a full buffer and uses it

Producers and consumers

• A solution to this problem must satisfy the following

conditions:

– A producer must not overwrite a ‘full’ buffer

– A consumer must not consume an ‘empty’ buffer

– Producers and consumers must access buffers in a mutually

exclusive manner

– An optional condition:

produced, i.e in FIFO order

Solution outline for producers–consumers

• The consumer checks for a full buffer inside of a critical section

• Q: What are the deficiencies of this solution? Busy waits!

An improved outline for a single buffer producers–consumers system using signaling

Indivisible operations for the producers–consumers problem

Readers and writers in a banking system

• A reader process merely reads values of account balances

• A writer process modifies account balances

Readers and writers

• Conditions to be satisfied by a solution to the

readers–writers problem

– Many readers may perform reading concurrently

– Reading is prohibited while a writer is writing

– Only one writer can perform writing at any time

– An optional condition:

Solution outline for readers–writers without writer priority

• Reading of data is not performed inside a critical section

• A write operation is performed inside a critical section

Dining philosophers

• A fork is placed between every pair of philosophers

• A philosopher needs two forks to eat; waits if a fork is not available

Outline of a philosopher process Pi

availability of forks one by one

• Q: Can starvation arise?

An improved outline of a philosopher process

• A philosopher checks for

both forks simultaneously

• Q: Does it avoid starvation?

• Q: Does it provide high

concurrency?

Concurrent systems

• Components of a concurrent system

– Processes

– Shared data: It can be of two kinds

we call it application data

* Synchronization data introduced to implement synchronization

– Operations on shared data can also be of two kinds

data)

• We introduce pictorial conventions to depict state of a

concurrent system—it is called a snapshot

Pictorial conventions for snapshots of concurrent systems

• Note the conventions for shared data, queue of blocked processes

and mutually exclusive operations (a dashed box)

Snapshots of the system of slide 16

check_aj, post_aj are mutually exclusive operations

Algorithmic approach to CS implementation

• In the algorithmic approach

– when a process wishes to use a CS, it checks a condition

– This approach does not require any support from the

architecture

– However, the condition could be complex

• This approach is not used in practice

– We study it to understand concurrency and race conditions

Two Process Algorithms: First attempt

• Processes enter their CSs according to the value of turn

• Q: Does it satisfy the progress, bounded wait properties ?

First attempt

• Properties of this solution:

– Processes enter the CS strictly by turn

– A process enters busy wait if it is not its turn to use the CS

which violates the progress condition

Second attempt

Second attempt

• Properties of this solution:

– A process enters the CS if the other process is not in CS

* Value of c 1 indicates whether process P 1 is in the CS

– Mutual exclusion is not ensured when both processes try to use the CS at the same time

* Exchanging the while statement with c 1 := 0 in P 1, and similarly in

– A process should wait for the other process if it also wishes to use the CS

situation is called a livelock condition

Dekker's algorithm

• This solution avoids deadlock and livelock problems

Q: How?

Dekker’s algorithm

• Employs useful elements of the previous two algorithms

– Variable turn is used to avoid livelocks

– Variables c1, c2 are used as status flags for P1 and P2 to indicate whether the process is interested in entering the CS

• Peterson’s algorithm (next slide) is simpler than Dekker’s

– The boolean array flag has an element for each process; it is

used analogous to c1, c2 of Dekker’s algorithm

Peterson's algorithm

• Show how mutual exclusion, progress and

bounded wait properties hold

An n process algorithm: Code of process Pi

• A process enters CS if none of the processes ahead of it in the

modulo order wishes to enter CS

• Q: How are race conditions avoided?

An n process algorithm

• Explanation of some features

– A process wishing to enter the CS checks whether some

process ahead of it in the modulo order starting on Pturn wishes to use the CS

– More than one process may reach the same conclusion (a race condition!)

(see the second while loop)

Bakery algorithm

• Features of the algorithm

– The algorithm hands out tokens to processes

previously issued tokens

– When a process wishes to enter the CS, it obtains a token

processes obtain a token at the same time

Bakery algorithm

• A process obtains a token and checks whether it may enter CS

• Q: What is the purpose

of the first while loop?

• Q: The second while loop?

Condition used in the Bakery algorithm

• Use of the following condition avoids a race condition:

If the token numbers are identical, the tie is broken by favouring

the process with the smaller process id

• What is a semaphore?

– A semaphore is a special integer that takes only non-negative

values on which only the following three operations can be

performed

Semantics of wait & signal operations

on semaphores

• The wait operation reduces the value of S if S > 0; otherwise it

blocks the process

• The signal operation wakes a process if processes are blocked

on the semaphore; otherwise, it increases the value of S

Uses of semaphores

• Semaphores can be put to three uses

– Mutual exclusion

– Bounded concurrency

up to n processes, 1 ≤ n ≤ c, where c is constant

– Signaling to ensure that an operation ai is performed after some

other operation aj

* A signal(S) operation is performed after a j

* A wait(S) operation is performed before a

CS implementation with semaphores

• Only one process can be in its critical section at any time

Snapshots of the concurrent system

of previous slide

Bounded concurrency using semaphores

• Up to 5 processes can simultaneously use a printer each

Signaling using semaphores

performed signal; otherwise, it will not be blocked

Single buffer producers–consumers

using semaphores

• The producer performs a wait on empty and signal on full

• The consumer performs a wait on full and signal on empty

Snapshots of single buffer producers–consumers

using semaphores

(a) Semaphore full is initialized to 0 and empty to 1

(b) Consumer performed wait (full) and got blocked; producer is producing

(c) Consumer is activated when producer finishes producing

Bounded buffers using semaphores

• n buffers exist

• prod_ptr points to next empty buffer, cons_ptr to next full buffer

• Q: How to generalize to multiple producers and consumers?

Readers–writers without writer priority

Refined solution outline

• The last exiting reader activates one writer

• An exiting writer activates either all waiting readers or one writer

Readers–writers using semaphores

• We use four counters

– runread : number of readers currently reading

– totread : number of readers currently waiting to read or reading – runwrite : number of writers currently writing

– totwrite : number of writers currently waiting to write or writing

Readers–writers using semaphores and four counters

• Readers and writers are controlled by a semaphores

reading and writing

• Mutex is used to avoid

race conditions on the counters

Implementation of Semaphores

• Three features are needed to implement semaphores

– Kernel support

– Use of lock variables

operations of a semaphore as indivisible operations

– Architectural assistance

reset the lock variable in a manner that prevents race conditions

Implementation of wait and signal operations

of semaphores

• A list of blocked processes is maintained

• block_me is a

system call that blocks the calling process

Methods of implementing semaphores

• Kernel-level implementation

– Kernel implements the wait and signal operations shown before

• User-level implementation

– wait and signal operations are coded as library procedures

* block_me and activate are also calls on library procedures

 It imposes some restrictions on concurrency and parallelism as in level threads

• Hybrid implementation

– wait and signal operations are implemented in a library

* block_me and activate are system calls

Problems in using semaphores

• Wait and signal operations are primitives

– They can be used in an arbitrary manner in a program, which

may lead to deadlocks, e.g., if a process implements a CS as

follows:

signal (mutex)

{ CS }

signal (mutex)

Q: Can it lead to correctness problems?

– Hence we need control structures for synchronization

Conditional Critical Region (CCR)

• CCR is a control structure on shared data x

• Features:

– Mutual exclusion

– The process in a CCR can use the await (boolean condition)

primitive

actions

Bounded buffer using conditional critical region

• A region do

statement is a CCR

• Producer awaits the condition

‘full < n’

• Consumer awaits the condition

‘full > 0’

Readers–writers without writer priority

is a CS on

read_write

Conditional critical regions

• Implementation outline:

– The boolean condition on which processes are blocked should

be checked periodically Any processes whose conditions have

become true should be activated

– Q: How often should a condition be checked?