Chapter 6 : Process Synchronization

Adopted from and based on Textbook: Operating System Concepts – 8th Edition, by Silberschatz, Galvin and Gagne Updated and Modified by Dr. Abdullah Basuhail, CSD, FCIT, KAU, 1431H

الرحيم الرحمن الله بسم

Chapter 6: Process Synchronization

CPCS361 – Operating Systems I

2Adopted from and based on Textbook: Operating System Concepts – 8th Edition, by Silberschatz, Galvin and Gagne Updated and Modified by Dr. Abdullah Basuhail, CSD, FCIT, KAU, 1431H

Module 6: Process Synchronization

Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems of

Synchronization Monitors Synchronization Examples Atomic Transactions


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


Background Cooperating processes can either directly

share a logical address space (i.e. both code and data) or be allowed to share data only through files or messages

Concurrent access to shared data may result in data inconsistency

Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes


Background Suppose that we wanted to provide a solution

to the consumer-producer problem that fills all the buffers. This can be done 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


Producer

while (true) { /* produce an item and put in nextProduced */

while (count == BUFFER_SIZE); // do nothing

buffer [in] = nextProduced; in = (in + 1) % BUFFER_SIZE; count++;

}


Consumer

while (true) {

while (count == 0) ; // do nothing nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE;

count--;

/* consume the item in nextConsumed */

}


Race Condition

Producer and consumer routines are correct separately they may not function correctly when executed concurrently Example:count = 5; concurrently:

producer executes count++; consumer executes count--;

count may be 4, 5, or 6!The only correct result is 5, if producer and consumer execute separately


Race Condition

count++count++ and count--count-- could be implemented as

register1 = countregister1 = register1 + 1count = register1

register2 = countregister2 = register2 - 1count = register2

10


Race Condition

Consider this execution interleaving with “count = 5” initially: S0: producer register1 = count {register1 =

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

S4: consumer count = register2 {count = 4}S5: producer count = register1 {count = 6 }



11


Race Condition

Incorrect state of count, because it is allowed for both processes to manipulate the variable count concurrently; this is called race condition.

Process synchronization and coordination is needed.



12


Critical-Section Problem Critical section: a process segment of code in

which a process may be changing common variables, updating a table, writing a file, and so on

When one process is executing in its critical section, no other process is allowed to execute in its critical section

do {entry section

critical sectionexit section

remainder section} while (TRUE);

13


Solution to Critical-Section Problem A solution to the critical-section problem must

satisfy the following three requirements:1. Mutual Exclusion - If process Pi is executing in its critical section, then no other processes can be executing in their critical sections2. 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

14


Solution to Critical-Section Problem3. Bounded Waiting - A bound, or limit 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 grantedAssume that each process executes at a

nonzero speed No assumption concerning relative speed of the

N processes

15


Peterson’s Solution Solution is restricted to two processes that

alternate execution between their critical sections and reminder sections

16


Peterson’s Solution 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! If both processes try to enter at the same time, turn will be set to both i and j at roughly the same time. Only

one of these will last; the other will occur but will be overwritten immediately The eventual value of turn decides which of the two processes is allowed to enter its critical section first

17


do {

flag[i] = TRUE;

turn = j;

while (flag[j] && turn == j);

critical section critical section

flag[i] = FALSE;

remainder remainder

section section

} while (TRUE);

Algorithm for Processes Pi and Pj

Pi

do {

flag[j] = TRUE;

turn = i;

while (flag[i] && turn == i);

critical section critical section

flag[j] = FALSE;

remainder section remainder section

} while (TRUE);

Pj

18


Algorithm for Processes Pi and Pj

Mutex is preserved: if Pi and Pj can be executing in their critical section at the same time, then flag[i] = flag[j] = true. Since turn can be either i or j one of the processes must have successfully executing the while statement

Pi will reset flag[i] to false allowing Pj to enter its critical section (progress) after at most one entry by Pi (bounded waiting)

19


Synchronization Hardware Many systems provide hardware support for

critical section code Uniprocessors – could disable interrupts

Currently running code would execute without preemption

Generally too inefficient on multiprocessor systems

Modern machines provide special atomic hardware instructions

Atomic = non-interruptable Either test memory word and set value Or swap contents of two memory words

20


Synchronization Hardware Race conditions are prevented by requiring

that critical regions be protected by locks A process must acquire a lock before entering

a critical section; it releases the lock when it exits the critical section

21


Solution to Critical-section Problem Using Locks

do { acquire lock

critical section release lock

remainder section } while (TRUE);

22


Semaphore Semaphore

S – integer variable Less complicated Accessed only through two standard atomic /indivisible

operations (when one process modify the semaphore value, no other process can simultaneously modify that same semaphore): wait() and signal() Originally called P() and V()

wait (S) { while S <= 0

; // no-op S--; }

signal (S) { S++; }

23


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 1do {

wait (mutex); // Critical Section signal (mutex);

// remainder section} while (TRUE);

24


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

can not be executed deadlock

25


Deadlock and Starvation Starvation – indefinite blocking. A process

may never be removed from the semaphore queue in which it is suspended. It may occur when processes are added or removed from the semaphore’s list in LIFO order.

26


Classical Problems of Synchronization

1. Bounded-Buffer Problem

2. Readers and Writers Problem

3. Dining-Philosophers Problem

27


Bounded-Buffer Problem Solution to the bounded-buffer problem using

semaphores Pool of 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

28


Bounded Buffer Problem (Cont.)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);

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

29


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 update (to 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 (writers have exclusive access to the shared data). No reader will be kept waiting unless a writer has already obtained permission to use the shared object.

30


Readers-Writers ProblemSolution: Shared Data Integer readcount initialized to 0

keeps track of how many processes are currently reading the object

Semaphore mutex initialized to 1 to ensure mutual exclusion when the variable readcount

is updated Semaphore wrt initialized to 1

mutual exclusion for the writers used by the first or last reader that enters or exits the

critical section

31


Readers-Writers Problem (Cont.)Structure of a writer process do { wait (wrt) ; // writing is

performed

signal (wrt) ; } while (TRUE);

Structure of a reader processdo {

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

32


Dining-Philosophers Problem

Shared data Bowl of rice (data set) Semaphore chopstick [5] initialized to 1

Eat

Think

33


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

34


End of Chapter 6

Chapter 6 : Process Synchronization

Documents

Transcript of Chapter 6 : Process Synchronization