Chapter 6: Process Synchronization

The University of Texas at Dallas

www.utdallas.edu

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

The University of Texas at Dallas

www.utdallas.edu

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

The University of Texas at Dallas

www.utdallas.edu

Producer Process
while (true) { /* produce an item in nextProduced */ while (count == BUFFER_SIZE) ; // do nothing buffer [in] = nextProduced; in = (in + 1) % BUFFER_SIZE; count++; }

The University of Texas at Dallas

www.utdallas.edu

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?
The University of Texas at Dallas www.utdallas.edu
5

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}
6

The University of Texas at Dallas

www.utdallas.edu

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 CriticalSection Problem must satisfy three requirements
The University of Texas at Dallas www.utdallas.edu
7

Critical-Section (CS) 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 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 Assumptions

Each process executes at a nonzero speed No restriction on the relative speed of the N processes
The University of Texas at Dallas www.utdallas.edu
8

Solutions for CS Problem

Disable interrupts during running CS
Currently running code would execute without preemption Possible only on uniprocessor systems. Why?
Uniprocessor: you prevent a context switch while in the CS (good) Multiprocessor: ok if CS data structure is in the kernel, not good if in shared memory between processes/threads

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

The University of Texas at Dallas www.utdallas.edu
9

Solution to Critical-section Problem Using Locks

do { acquire lock critical section release lock remainder section } while (TRUE);

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

//Go up the levels

The University of Texas at Dallas

www.utdallas.edu

The University of Texas at Dallas

www.utdallas.edu

Petersons Solution (as in the book)

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
29

The University of Texas at Dallas

www.utdallas.edu

Algorithm for Process Pi

while (true) { flag[i] = TRUE; turn = j; while (flag[j] && turn == j) ; /* just wait*/ CRITICAL SECTION flag[i] = FALSE; Access non-critical-section areas }
Does this algorithm satisfy the three requirements?
Yes. Show this as an exercise.
The University of Texas at Dallas www.utdallas.edu
30

Process 0 Process 1 while (true) { while (true) { flag[0] = TRUE; flag[1] = TRUE; turn = 1; turn = 0; while (flag[1] && turn == 1) while (flag[0] && turn == 0) ; /* just wait*/ ; /* just wait*/ CRITICAL SECTION CRITICAL SECTION flag[0] = FALSE; flag[1] = FALSE; Access non-critical-section Access non-critical-section are areas } }

The University of Texas at Dallas

www.utdallas.edu

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

Modern machines provide special atomic (noninterruptable) hardware instructions

Either test a memory word and set value Or swap contents of two memory words

The University of Texas at Dallas

www.utdallas.edu

32

TestAndndSet Instruction
Definition: boolean TestAndSet (boolean *target) { boolean rv = *target; *target = TRUE; return rv; }

The University of Texas at Dallas

www.utdallas.edu

33

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. The University of Texas at Dallas www.utdallas.edu
34

The University of Texas at Dallas

www.utdallas.edu

Swap Instruction
Definition: void Swap (boolean *a, boolean *b) { boolean temp = *a; *a = *b; *b = temp; }

The University of Texas at Dallas

www.utdallas.edu

36

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 }
The University of Texas at Dallas www.utdallas.edu
37

Semaphores
Much easier to use than hardware-based solutions Semaphore S integer variable Two standard operations to modify S:
wait() signal()

These two operations are indivisible (atomic)

The University of Texas at Dallas

www.utdallas.edu

38

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
The University of Texas at Dallas www.utdallas.edu
39

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 1 wait (mutex); Critical Section signal (mutex);
The University of Texas at Dallas www.utdallas.edu
40

Semaphore Types and Usage (contd)

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 instances

e.g., producer-consumer problem with finite buffer
41

The University of Texas at Dallas

www.utdallas.edu

Semaphore Implementation with no Busy Waiting Each semaphore has:

value (of type integer) waiting queue Two internal 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

The University of Texas at Dallas

www.utdallas.edu

42

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

Semaphore Implementation with no Busy Waiting

signal (S) { value++; if (value <= 0) { /*some processes are waiting*/ remove a process P from waiting queue wakeup(P); } }
The University of Texas at Dallas www.utdallas.edu
43

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 not we 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)
The University of Texas at Dallas www.utdallas.edu
44

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
45

The University of Texas at Dallas

www.utdallas.edu

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)

The University of Texas at Dallas

www.utdallas.edu

46

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

The University of Texas at Dallas

www.utdallas.edu

47

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

The University of Texas at Dallas

www.utdallas.edu

48

Bounded Buffer Problem (contd)

Structure of the producer process while (true) { // produce an item wait (empty); wait (mutex); // add item to buffer signal (mutex); signal (full); }
The University of Texas at Dallas www.utdallas.edu
49

Bounded Buffer Problem (contd)

Structure of the consumer process while (true) { wait (full); wait (mutex); // remove an item from buffer signal (mutex); signal (empty); // consume removed item }
The University of Texas at Dallas www.utdallas.edu
50

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

The University of Texas at Dallas

www.utdallas.edu

51

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
The University of Texas at Dallas www.utdallas.edu
52

 A data set is shared among a number of concurrent processes

Readers-Writers Problem

Readers only read the data set; they do not perform any updates Writers can 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
The University of Texas at Dallas

www.utdallas.edu

53

Readers-Writers Problem (contd)

The structure of a writer process while (true) { wait (wrt) ; // writing is performed signal (wrt) ; }
The University of Texas at Dallas www.utdallas.edu
54

Readers-Writers Problem (contd)

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) ; } The University of Texas at Dallas www.utdallas.edu
55

Readers-Writers Problem (contd)

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
The University of Texas at Dallas www.utdallas.edu
56

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 to The University of Texas suspend/awake processes at Dallas

www.utdallas.edu

57

Monitors
Monitor: High-level abstraction that provides a convenient and effective mechanism for process synchronization
Compiler (not programmer) takes care of mutual exclusion

Only one process may be active within the monitor at a time monitor monitor_name { //shared variable declarations procedure P1 () { . } procedure Pn () {} Initialization code ( .) { } } The University of Texas at Dallas www.utdallas.edu
58

Schematic View of Monitors

59

The University of Texas at Dallas

www.utdallas.edu

Solution to Dining Philosophers

monitor DP { enum {THINKING, HUNGRY, EATING} state [5] ; condition self [5];
void pickup (int i) { state[i] = HUNGRY; test(i); //check both chopsticks, // set state[i] = EATING if both are available if (state[i] != EATING) self [i].wait; } void putdown (int i) { state[i] = THINKING; // test left and right neighbors test((i + 4) % 5); // right test((i + 1) % 5); // left } The University of Texas at Dallas

www.utdallas.edu

60

Solution to Dining Philosophers (contd)

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
61

The University of Texas at Dallas

www.utdallas.edu

Solution to Dining Philosophers (contd)

Each philosopher invokes the operations pickup() and putdown() in the following sequence: dp.pickup (i) EAT dp.putdown (i)

The University of Texas at Dallas

www.utdallas.edu

62

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 java programs for the Producer-Consumer and dinning philosophers problems

The University of Texas at Dallas

www.utdallas.edu

63

Synchronization Examples
Windows XP
Linux Pthreads

The University of Texas at Dallas

www.utdallas.edu

64

Windows XP Synchronization
Masks interrupts to protect access to global resources on uniprocessor systems (inside kernel) Uses spinlocks on multiprocessor systems
Provides dispatcher objects for thread synchronization outside kernel, which can act as mutexes, semaphores, or events (condition variables)

The University of Texas at Dallas

www.utdallas.edu

65

Linux Synchronization
Linux:
disables interrupts to implement short critical sections (on single processor systems)

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

The University of Texas at Dallas

www.utdallas.edu

66

Pthreads Synchronization
Pthreads API is OSindependent It provides:
mutex locks condition variables
#include <pthread.h> pthread_mutex_t mutex;

67

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

extensions include:
semaphores read-write locks spin locks

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

The University of Texas at Dallas

Summary
Processor Synchronization

68

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: Petersons Algorithm Hardware support: TestAndSet(), Swap()
Busy waiting (or spinlocks)

Semaphores:
wait(), signal() must be atomic moves the CS problem to kernelThe University of Texas at Dallas www.utdallas.edu