1

School of Computing ScienceSimon Fraser University

CMPT 300: Operating Systems ICMPT 300: Operating Systems I

Ch 6: Process SynchronizationCh 6: Process Synchronization

Dr. Mohamed HefeedaDr. Mohamed Hefeeda

2

Objectives

Understand The Critical-Section Problem And its hardware and software solutions

3

Consumer-Producer Problem

Classic example of process coordination Two processes sharing a buffer One places items into the buffer (producer)

Must wait if the buffer is full The other takes items from the buffer

(consumer) Must wait if buffer is empty

Solution: Keep a counter on number of items in the buffer

4

Producer Process

while (true) { /* produce an item in

nextProduced */ while (count == BUFFER_SIZE); // do nothing buffer [in] = nextProduced; in = (in + 1) % BUFFER_SIZE; count++;

}

5

Consumer Process

while (true) { while (count == 0) ; // do nothing nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; count--;/*consume item in nextConsumed */}

What can go wrong with this solution?

6

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 executes register1 = count {register1 = 5}S1: producer executes register1 = register1 + 1 {register1 = 6} S2: consumer executes register2 = count {register2 = 5} S3: consumer executes register2 = register2 - 1 {register2 = 4} S4: producer executes count = register1 {count = 6 } S5: consumer executes count = register2 {count = 4}

7

Race Condition

Occurs when multiple processes manipulate shared data concurrently and the result depends on the particular order of manipulation

Data inconsistency may arise Solution idea

Mark code segment that manipulates shared data as critical section

If a process is executing its critical section, no other processes can execute their critical sections

More formally, any method that solves the Critical-Section Problem must satisfy three requirements …

8

Critical-Section (CS) Problem1. 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 selection of the process 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

AssumptionsEach process executes at a nonzero speed No restriction on the relative speed of the N processes

9

Solutions for CS Problem Disable interrupts during running CS

Currently running code would execute without preemption

Possible only on uniprocessor systems. Why?• Every processor has its own interrupts• Disabling interrupts in all processors is inefficient

Any problems with this solution even on uniprocessor systems?• Users could make CS arbitrary large

unresponsive system

Solutions using software only Solutions using hardware support

10

Peterson’s Solution Software solution; no hardware support Two process solution Assume LOAD and STORE instructions are

atomic (i.e., cannot be interrupted) may not always be true in modern computers

The two processes share two variables: int turn; Boolean flag[2];

turn indicates whose turn it is to enter critical section

The flag array indicates whether a process is ready to enter critical section flag[i] = true ==> process Pi is ready

11

Algorithm for Process Pi

while (true) { flag[i] = TRUE; turn = j; while (flag[j] && turn == j) ; CRITICAL SECTION flag[i] = FALSE; REMAINDER SECTION }

Does this algorithm satisfy the three requirements?Yes. Show this as an exercise.

12

Synchronization Hardware

Many systems provide hardware support for critical section code more efficient and easier for programmers

Modern machines provide special atomic (non-interruptable) hardware instructionsEither test a memory word and set valueOr swap contents of two memory words

13

TestAndndSet Instruction

Definition:

boolean TestAndSet (boolean *target)

{ boolean rv = *target; *target = TRUE; return rv; }

14

Solution using TestAndSet Shared boolean variable lock, initialized to

false while (true) { while ( TestAndSet (&lock ) ) ; /* do nothing

// critical section

lock = FALSE; // remainder section } Does this algorithm satisfy the three requirements?NO. A process can wait indefinitely for another faster process that is accessing its CS. Check Fig 6.8 for a modified version.

15

Swap Instruction

Definition: void Swap (boolean *a, boolean

*b) { boolean temp = *a; *a = *b; *b = temp; }

16

Solution using Swap Shared boolean variable lock initialized to

FALSE; Each process has a local boolean variable key while (true) { key = TRUE; while ( key == TRUE) Swap (&lock, &key ); // critical section lock = FALSE; // remainder section }

17

Semaphore

Much easier to use than hardware-based solutions

Semaphore S – integer variableTwo standard operations to modify S:

wait()signal()

These two operations are indivisible (atomic)

18

Semaphore Operations

wait (S) { while (S <= 0)

; // no-op, called busy waiting, spinlock S--;}

signal (S) { S++;}

Later, we will see how to implement these operations with no busy waiting

19

Semaphore Types and Usage

Two types Counting semaphore: can be any integer value Binary semaphore: can be 0 or 1 (known as mutex

locks)

Usage examples:

Mutual exclusion Semaphore mutex; // initialized to 1wait (mutex); Critical Sectionsignal (mutex);

20

Semaphore Types and Usage (cont’d)

Process synchronization: S2 in P2 should be executed after S1 in P1

P1:S1;signal (sem);

P2:wait (sem);S2;

Control access to a resource with finite number of instancese.g., producer-consumer problem with finite

buffer

21

Semaphore Implementation with no Busy Waiting

Each semaphore has: value (of type integer) waiting queue

Two operations: block – place the process invoking the operation in

the waiting queue wakeup – remove one of the processes from the

waiting queue and place it in the ready queue

22

Semaphore Implementation with no Busy Waiting

wait (S) { value--; if (value < 0) { add this process to waiting queue block(); }

} signal (S) {

value++; if (value <= 0) { /*some processes are waiting*/ remove a process P from waiting queue wakeup(P);

} }

23

Semaphore Implementation Must guarantee that no two processes can

execute wait and signal on same semaphore at same time

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

Disabling interrupts (uniprocessor systems only) Busy waiting or spinlocks (multiprocessor systems)

Well, why do we not do the above in applications?

Applications may spend long (and unknown) amount of time in critical sections, unlike kernel which spends short and known beforehand time in critical section (~ ten instructions)

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 1P0 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

25

Classical Problems of Synchronization

Bounded-Buffer (Producer-Consumer) Problem Dining-Philosophers Problem Readers-Writers Problem

These problems are abstractions that can be used to model many other

resource sharing problems used to test newly proposed synchronization

schemes

26

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

27

Bounded Buffer Problem (cont’d)

Structure of the producer process while (true) { // produce an item wait (empty); wait (mutex); // add item to buffer signal (mutex); signal (full); }

28

Bounded Buffer Problem (cont’d)

Structure of the consumer process while (true) { wait (full); wait (mutex); // remove an item from buffer signal (mutex); signal (empty); // consume removed item }

29

Dining-Philosophers Problem

Philosophers alternate between eating and thinking To eat, a philosopher needs two chopsticks (at her left and right)

Models multiple processes sharing multiple resources Write a program for each philosopher s.t. no

starvation/deadlock occurs Solution approach:

Bowl of rice (data set) Array of semaphores: chopstick [5] initialized to 1

30

Dining-Philosophers Problem: Philosopher i

While (true) { wait ( chopstick[i] );

wait ( chopstick[ (i + 1) % 5] ); // eat signal ( chopstick[i] ); signal (chopstick[ (i + 1) % 5] );

// think}

What can go wrong with this solution? All philosophers pick their left chopsticks at

same time (deadlock) Solutions?

Pick chopsticks only if both are available Asymmetric: odd philosopher picks left

chopstick first, even picks right first

31

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

32

Readers-Writers Problem (cont’d)

The structure of a writer process while (true) { wait (wrt) ; // writing is performed

signal (wrt) ; }

33

Readers-Writers Problem (cont’d) Idea of reader processes:

The first reader needs to check that there is no writer in CS Other readers access CS right away, but they need to update

the current number of readers in CS (readcount)

while (true) { wait (mutex) ; // mutex: protects readcount

readcount ++ ; if (readercount == 1) wait (wrt) ;

signal (mutex) // reading is performed

wait (mutex) ; readcount - - ; if (redacount == 0) signal (wrt) ; signal (mutex) ; }

34

Readers-Writers Problem (cont’d)

Some systems implement reader-writer locks E.g., Solaris, Linux, Pthreads API A process can ask for a reader-write lock either in

read or write mode

When would you use reader-writer locks? Applications where it is easy to identify readers only

and writers only processes Applications with more readers than writers

Tradeoff: cost vs. concurrency Reader-writer locks require more overhead to

establish than semaphores, but they provide higher concurrency by allowing multiples readers in CS

35

Be Careful When Using Semaphores

Some common programming problems …

signal (mutex) …. wait (mutex)• Multiple processes can access CS at the

same time

wait (mutex) … wait (mutex)• Processes may block for ever

Forgetting wait (mutex) or signal (mutex)

36

Monitors Monitor: High-level abstraction that provides a convenient

and effective mechanism for process synchronization Compiler (not programmer) takes care of mutual exculsion

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

monitor monitor_name{

//shared variable declarations

procedure P1 (…) { …. }…procedure Pn (…) {……}

Initialization code ( ….) { … }}

37

Schematic View of a Monitor

38

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

What is the difference between condition variables and semaphores?

condition variable: if no process is suspended, signal has no effect

semaphores: signal always increments semaphore's value

Condition variables are usually used in monitors to provide a way to suspend/awake processes

39

Monitor with Condition Variables

40

Solution to Dining Philosophersmonitor DP {

enum {THINKING, HUNGRY, EATING} state [5] ;condition self [5];

void pickup (int i) { state[i] = HUNGRY; test(i); //check both chopsticks 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);

}

41

Solution to Dining Philosophers (cont’d)

void test (int i) { if ( (state[i] == HUNGRY) &&

(state[(i + 4) % 5] != EATING) && (state[(i + 1) % 5] != EATING) ) {

state[i] = EATING ; self[i].signal () ;

} } initialization_code() {

for (int i = 0; i < 5; i++) state[i] = THINKING;

}} // end monitor

42

Solution to Dining Philosophers (cont’d)

Each philosopher invokes the operations pickup() and putdown() in the following sequence:

dp.pickup (i)

EAT

dp.putdown (i)

43

Monitors Implementation

It is up to the compiler to ensure mutual exclusion in monitors Semaphores are usually used

Languages like Java, C# (not C), and Concurrent Pascal provide monitors-like mechanisms

Java public class SimpleClass {

....public synchronized void insert(…) { …}public synchronized void remove(…) { …}….

} Java guarantees that once a thread starts executing a

synchronized method, no other thread can execute any other synchronized method in the class

Java 1.5 has semaphores, condition variables, mutex locks, …

In java.util.concurrent package

Exercise: write a java solution for the Producer-Consumer problem

44

Synchronization Examples

Windows XP

Linux

Pthreads

45

Windows XP Synchronization

Masks interrupts to protect access to global resources on uniprocessor systems (inside kernel)

Uses spinlocks on multiprocessor systems

Also provides dispatcher objects for thread synchronization outside kernel, which can act as mutexes, semaphores, or events (condition variables)

46

Linux Synchronization

Linux: disables interrupts to implement short critical

sections (on single processor systems)

Linux provides: semaphores Spinlocks (on SMP) Reader-writer locks

47

Pthreads Synchronization

Pthreads API is OS-independent

It provides: mutex locks condition variables

extensions include: semaphores read-write locks spin locks May not be portable

#include <pthread.h>pthread_mutex_t mutex;

pthread_mutex_init(&mutex, null);pthread_mutex_lock(&mutex);pthread_mutex_unlock(&mutex);

#include <semaphore.h>sem_t sem;sem_init(&sem, 0, 5);sem_wait(&sem);sem_post(&sem);

48

Summary Processor Synchronization

Techniques to coordinate access to shared data Race condition

Multiple processes manipulating shared data and result depends on execution order

Critical section problem Three requirements: mutual exclusion, progress,

bounded waiting Software solution: Peterson’s Algorithm Hardware support: TestAndSet(), Swap()

• Busy waiting (or spinlocks) Semaphores:

• wait(), signal() must be atomic moves the CS problem to kernel

Monitors: high-level constructs (compiler) Some classical synchronization problems