6.1 Silberschatz, Galvin and Gagne 2005 Operating System Concepts Chapter 5: Process Synchronization Background The Critical-Section Problem Petersons

6.1 Silberschatz, Galvin and Gagne ©2005Operating System Concepts

Chapter 5: Process SynchronizationChapter 5: Process Synchronization

Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware based solution Semaphores based solution Classic Problems of Synchronization Monitors – Language level solution Synchronization Examples


BackgroundBackground

Concurrent access to shared data may result in data inconsistency. Maintaining data consistency requires mechanisms to ensure the

orderly execution of cooperating processes. Bounded buffer problem:

There are N buffers Two types of processes, namely, Consumers and Producers

have access to the N buffers. Producers produce items and place the items in the empty

buffers. Consumers consume the items placed in the buffers Producers and consumers need to be synchronized to access

the shared resource (buffers).


An Incorrect Solution to the Bounded-An Incorrect Solution to the Bounded-Buffer ProblemBuffer Problem

Shared data

#define BUFFER_SIZE 10typedef struct {

. . .} item;

item buffer[BUFFER_SIZE];int in = 0;int out = 0;int counter = 0;


An Incorrect Solution to …An Incorrect Solution to …

A Producer process

item nextProduced;

while (1) {while (counter == BUFFER_SIZE)

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

}



A Consumer process

item nextConsumed;

while (1) {while (counter == 0)

; /* do nothing */nextConsumed = buffer[out];out = (out + 1) % BUFFER_SIZE;counter--;

}



The statements

counter++;counter--;

must be performed atomically.

Atomic operation means an operation that completes in its entirety without interruption.



The statement “counter++” may be implemented in machine language as:

register1 = counterregister1 = register1 + 1counter = register1

The statement “counter--” may be implemented as:

register2 = counterregister2 = register2 – 1counter = register2



If both the producer and consumer attempt to update the buffer concurrently, the assembly language statements may get interleaved.

Interleaving depends upon how the producer and consumer processes are scheduled.



Assume counter is initially 5. One interleaving of statements is:

producer: register1 = counter (register1 = 5)producer: register1 = register1 + 1 (register1 = 6)consumer: register2 = counter (register2 = 5)consumer: register2 = register2 – 1 (register2 = 4)producer: counter = register1 (counter = 6)consumer: counter = register2 (counter = 4)

The value of count may be either 4 or 6, where the correct result should be 5.


Race ConditionRace Condition

Race condition: The situation where several processes access and manipulate shared data concurrently. The final value of the shared data depends upon which process finishes last.

To guard against inconsistencies that would arise due to race conditions, concurrent processes must be synchronized.


The Critical-Section ProblemThe Critical-Section Problem

n processes all competing to use some shared data Each process has a code segment, called critical section, in

which the shared data is accessed. The Critical section Problem – ensure that when one process

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


Requirements of a Solution to Critical-Section Requirements of a Solution to Critical-Section ProblemProblem

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 process that will enter the critical section next cannot be postponed indefinitely.

3. Bounded Waiting. A bound must exist on the number of times 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.


Support for Solving the Critical Section Support for Solving the Critical Section ProblemProblem

No Support: It is the programmers responsibility to ensure mutually exclusive access to shared resources when several processes are allowed to access a resource concurrently

Hardware support: Some hardware instructions are provided to support the programmer (e.g., ‘testandset’, and ‘swap’ instructions)

Operating System Support: Operating system supports for the declaration of data structures and also operations on those data structures (e.g., semaphores)

High Level Language Support: Language provides support for data structures and operations on them to help with synchronization. (e.g., critical regions, monitors, serializers, etc)


Initial Attempts to Solve the Problem Initial Attempts to Solve the Problem Without any Support Without any Support

Only 2 processes, P0 and P1

General structure of process Pi (other process Pj where j=1-i)

do {

entry sectioncritical section

exit sectionremainder section

} while (1); Processes may share some common variables to

synchronize their actions.


Algorithm 1Algorithm 1

Shared variables: int turn;

initially turn = 0 (turn ==i) Pi can enter its critical section

Process Pi :

do {

while (turn != i) ; // loop if it is not my turn

critical section

turn = j; remainder section

} while (1); Satisfies mutual exclusion, but not progress requirement because it

requires strict alternation of processes.


Algorithm 2Algorithm 2

Shared variables boolean flag[2];

initially flag [0] = flag [1] = false. flag [i] = true Pi is ready to enter its critical section

Process Pi

do {flag[i] = true;while (flag[j]) ; critical sectionflag [i] = false;remainder section} while (1);

Satisfies mutual exclusion, but still does not satisfy progress requirement because what if (flag[i] == true) and (flag[j] == true);


Algorithm 3 (Peterson’s Solution)Algorithm 3 (Peterson’s Solution)

Combined the ideas of algorithms 1 and 2. Process Pi

do {flag [i]= true;turn = j;while (flag [j] and turn == j) ;

critical sectionflag [i] = false;

remainder section} while (1);

Meets all three requirements; solves the critical-section problem for two processes.


Synchronization HardwareSynchronization Hardware

Many systems provide hardware support for synchronizing 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-interruptible Either test memory word and set a value Or swap contents of two memory words


TestAndndSet Instruction TestAndndSet Instruction

Definition:

// This Instruction returns the current value of target and //sets it, value to TRUE atomically. boolean TestAndSet (boolean *target)

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


Solution using TestAndSetSolution using TestAndSet

Shared boolean variable lock., initialized to false. Solution: do { while ( TestAndSet (&lock )) ; /* do nothing

// critical section

lock = FALSE;

// remainder section

} while ( TRUE);Note: This solution ensures mutual exclusion, and progress property but

does not meet bounded waiting criteria


Swap InstructionSwap Instruction

Definition: //This instruction swaps the values of a and b atomically. void Swap (boolean *a, boolean *b) { boolean temp = *a; *a = *b; *b = temp: }


Solution using SwapSolution using Swap Shared Boolean variable lock, initialized to FALSE; Each process

has a local Boolean variable key. Solution: do { key = TRUE; while ( key == TRUE) Swap (&lock, &key ); // critical section lock = FALSE; // remainder section

} while ( TRUE);Note: This solution also does not meet the bounded waiting criteria.


A solution satisfying all the three criteriaA solution satisfying all the three criteria

Shared data (initialized to false): boolean lock;

boolean waiting[n]; // n is the total number of processes. Process Pi

do { waiting[i]=true;

key = true;while (waiting[i] && key ) key=TestAndSet(lock);

waiting[i]=false;critical sectionj = (i+1)% n;

while ((j!=i) && !waiting[j]) j=(j+1) % n; if (j==i) // if no process is waiting for access to CS lock=false; else waiting[j]=false; // signal a waiting process

remainder section

} while(1);


Mutex LocksMutex Locks

The hardware-based solutions are inaccessible to application programmers. So, Operating system designers build software tools to help programmers solve

the critical section problem. One such tool is mutex locks. ( i.e., a process must acquire the lock before entering critical section.)

A mutex lock has a boolean variable available whose value indicates whether the lock is available or not. The acquire() function acquires the lock and the release() function releases the lock.

The definition of acquire(). The definition of release() acquire() { release(){ while (!available) available = true;

; } available = false; }


Solution to the critical section problem Solution to the critical section problem using mutex locksusing mutex locks

Do {

acquire lock

critical section

release lock

remainder section

}while(true)


SemaphoresSemaphores

All of the above solutions require busy waiting (spin locks) Goal : To design and implement a synchronization tool that does

not require busy waiting. Semaphore S – an integer variable A semaphore can only be accessed via two indivisible (atomic)

operationswait (S):

while (S 0) ; // no-op;

S--;

signal (S): S++;


Solution to Critical Section Problem Solution to Critical Section Problem Using SemaphoreUsing Semaphore

Shared data: semaphore mutex; // initially mutex = 1

Process Pi:

do { wait(mutex); critical section

signal(mutex); remainder section} while (1);

This still doesn’t satisfy the bounded waiting property. Another problem with all the solutions described so far is that a process trying to enter critical section has to busy-wait in a loop. This wastes CPU cycles.


Priority inversionPriority inversion

What happens when a higher priority process needs to read or modify the kernel data that are currently being accessed by a lower-priority process and the lower priority process is preempted in favor of higher priority process (this happens often in real time systems) -- Deadlock

Solution: (Priority-inheritance protocol) All processes that are accessing resources needed by a higher priority process inherit the higher priority until they are finished with the resources in question.

This protocol was designed by by L.Sha, R. Rajkumar and J.P. Lehoczky. See the related story about the NASA’s Mars Path finder probe (1997) that landed

a robot, the Soujourner rover, on Mars which had a software bug. Information about it can be found at: http://users.ece.cmu.edu/~raj/mars.html or at http://research.microsoft.com/en-us/um/people/mbj/Mars_Pathfinder/Mars_Pathfinder.html

http://users.ece.cmu.edu/~raj/mars.html


A Semaphore Implementation that A Semaphore Implementation that Prevents Busy-WaitingPrevents Busy-Waiting

New definition of semaphore: Define a semaphore as a record

typedef struct { int value; struct process *L;} semaphore;

Assume two simple operations: block suspends the process that invokes it. wakeup(P) resumes the execution of a blocked process P.


A Semaphore Implementation A Semaphore Implementation

Semaphore operations are now defined as (Recall that these operations are atomic)

wait(S):S.value- -;if (S.value < 0) {

add this process to S.L;block;

}

signal(S): S.value+ +;if (S.value <= 0) {

remove a process P from S.L;wakeup(P);

}

Note: This implementation of semaphore solves the busy-wait problem


Semaphore as a General Synchronization ToolSemaphore as a General Synchronization Tool

To execute B in Pj only after A is executed in Pi

Use semaphore flag with flag.value initialized to 0 Code:

Pi Pj

A wait(flag)

signal(flag) B


Deadlock and StarvationDeadlock 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); Deadlock – indefinite blocking. A process may never be removed from the

semaphore queue in which it is suspended.


Classical Problems of SynchronizationClassical Problems of Synchronization

Bounded-Buffer Problem

Readers and Writers Problem

Dining-Philosophers Problem


Bounded-Buffer ProblemBounded-Buffer Problem

Shared data

semaphore full, empty, mutex;

Initially:

full.value = 0, empty.value = n, mutex.value = 1


Bounded-Buffer Problem - Producer ProcessBounded-Buffer Problem - Producer Process

Producer Process:do {

…produce an item in nextp

…wait(empty);wait(mutex);

…add nextp to buffer

…signal(mutex);signal(full);

} while (1);


Bounded-Buffer Problem - Consumer ProcessBounded-Buffer Problem - Consumer Process

Consumer Process:do {

wait(full)wait(mutex);

…remove an item from buffer to nextc

…signal(mutex);signal(empty);

…consume the item in nextc

…} while (1);


Readers-Writers ProblemReaders-Writers Problem

Shared data int readcount; semaphore mutex, // to synchronize access to ‘readcount’ wrt; // to ensure mutual exclusion among // writers

Initially

mutex.value = 1, wrt.value = 1, readcount = 0

Writer Process:wait(wrt);

…writing is performed

…signal(wrt);


Readers-Writers Problem - Reader ProcessReaders-Writers Problem - Reader ProcessReader Process:

wait(mutex); // synchronize access to variable readcount readcount++;if (readcount == 1) // if I am the first reader, then I wait for the writer writing and the writers wait(wrt); // waiting and block all the incoming writers.signal(mutex);

…reading is performed …wait(mutex);readcount--; if (readcount == 0) // If there is no more reader, then

signal(wrt); // wake up a waiting writersignal(mutex);

A Problem with this solution: Writers will starve. Try to modify the solution to prevent starvation.


Dining-Philosophers ProblemDining-Philosophers Problem

Shared data

semaphore chopstick[5];Initially, chopstick[i].value =1, for i=0,1,2,3,4.


Dining-Philosophers Problem Dining-Philosophers Problem

Philosopher i:do {

wait(chopstick[i])wait(chopstick[(i+1) % 5])

…eat …

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

…think …

} while (1);

Problem with this solution: deadlock.


Monitors (Language level support)Monitors (Language level support) High-level synchronization construct that allows the safe sharing of an abstract data

type among concurrent processes.

monitor monitor-name{shared variable declarationsprocedure body P1 (…) {. . .}procedure body P2 (…) {. . .} procedure body Pn (…) { . . .} {initialization code}}


Semantics of MonitorsSemantics of Monitors

Only one process can be active inside the monitor. i.e., when one process is executing a procedure inside the monitor, no other process can be executing any procedure of the monitor

To allow a process to wait within the monitor, a condition variable must be declared, ascondition x, y;

A Condition variable can only be used with the operations wait , signal and queue. The operation

x.wait();means that the process invoking this operation is suspended and placed in the queue associated with x until another process invokes

x.signal(); The x.signal operation resumes exactly one suspended process in the queue associated

with x. If there is no process in the queue associated with x, then the signal operation has no effect.

The x.queue operation returns true or false depending on whether a process is waiting in the queue associated with the condition variable x. This operation does not have any other effect on x.


Schematic View of a MonitorSchematic View of a Monitor


Monitor With Condition VariablesMonitor With Condition Variables


Dining Philosophers ExampleDining Philosophers Examplemonitor dp {

enum {thinking, hungry, eating} state[5];condition self[5];void pickup(int i) // following slidevoid putdown(int i) // following slidevoid test(int i) // following slidevoid init() {

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

}}


Solution to Dining Philosophers ProblemSolution to Dining Philosophers Problemvoid pickup(int i) {

state[i] = hungry;test(i);if (state[i] != eating)self[i].wait();}

void putdown(int i) {state[i] = thinking;

// test and signal left // and right neighbors

test((i+4) % 5);test((i+1) % 5);}

void test(int i) {if ( (state[(i+ 4) % 5] != eating) && (state[i] == hungry) &&(state[(i + 1) % 5] != eating)) {state[i] = eating;self[i].signal();}}

=========================== Philosopher i:Do{ dp.pickup(i); eat; // Critical section dp.putdown(i); think;}


Synchronization in LinuxSynchronization in Linux

The simplest synchronization is the atomic integer, which is represented using the opaque data type atomic_t (a data type is opaque if it can only be modified or read by accessing subroutines) Usage of this datatype:

atomic_t counter;

int value;

atomic_set(&counter 10);

atomic_add(5, &counter);

atomic_sub(10, &counter);

atomic_inc(&counter);

value = atomic_read(&counter); mutex_lock() , mutex_unlock() : These are similar to wait and signal operation on

semaphores for protecting critical sections within the kernel. spinlocks() and semaphores: Will talk more about this when I assign the

programming assignment.


Solaris 2 SynchronizationSolaris 2 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. An adaptive mutex starts as a standard semaphore implemented as a

spinlock. These are used to protect short critical sections (i.e., for less than a few hundred instructions).

If the lock is held by a process that is currently running on another CPU, the thread spins while waiting for the lock to become available, because the thread holding the lock is likely to finish soon

If the thread holding the lock is not currently in run state, the thread blocks and goes to sleep until it is awaken while the lock is released.

So, on a uniprocessor system, a thread always sleeps if it encounters a lock being held by another process, because a thread holding the lock cannot be running when another process is testing the lock

condition variables and semaphores are used for protecting longer critical sections If the desired lock is already held, the process issues a wait and sleeps When a thread frees a lock, it issues a signal to the next sleeping thread in the

queue The extra cost of putting a thread to sleep and waking it up, and the associated

context switches, is less than the cost of wasting several hundred instructions waiting in spinlock.


Solaris 2 Synchronization…Solaris 2 Synchronization…

readers-writers locks are used to protect data that are accessed frequently but usually in a read-only manner. These are also used for protecting long sections of code.

Uses turnstiles to order the list of processes waiting to acquire either an adaptive mutex or reader-writer lock. A turnstile is a queue structure containing threads blocked on a

lock. To prevent priority inversion problem, turnstiles are organized

according to a priority inheritance protocol This means, that if a lower priority process currently holds a lock

that a higher priority process is blocked on, then the lower priority process holding the lock will temporarily inherit the priority of the higher priority process. Upon releasing the lock, the process will revert to its original priority.


Windows 2000 SynchronizationWindows 2000 Synchronization Uses interrupt masks to protect access to global resources on uniprocessor systems.

Uses spinlocks on multiprocessor systems. Just as in Solaris 2, the kernel uses spinlocks only to protect short code Moreover the kernel ensures that the process will never be preempted while holding

a spinlock Also provides dispatcher objects to provide synchronization outside the kernel

Using a dispatcher object, a process can synchronize according to several different mechanisms including mutexes, semaphores and events

Shared data can be protected by requiring a thread to gain ownership of a mutex to access the data and release ownership when it is finished.

Events are a synchronization mechanisms which act much like a condition variable. Dispatcher objects may be signaled or nonsignaled

A signaled state indicates that an object is not available and a process will not block when acquiring the object

A nonsignaled state indicates that an object is not available and the process will block when attempting to acquire the object

When the state of a dispatcher object changes to signaled, the kernel checks if there is any processes waiting on this object and if so, it moves one or more processes from the waiting state to ready state where they can resume execution


An Alternative Approach –Transactional An Alternative Approach –Transactional MemoryMemory

A concept borrowed from databases. A memory transaction is a sequence of memory read-write operations that are atomic. i.e. If all operations in a transaction are completed, the memory transaction is

committed. Otherwise, the operations must be aborted and rolled back. Consider the following example:

void update(){

Wait(P) /* modify data*/ Signal(P)

} As we know, using synchronization mechanisms can lead to deadlock if improperly

used. However, new features such as atomic{S} that take advantage of transactional memory can be added to the programming language. Then the update() function above can be written as void update(){

atomic{ /* modify data*/ }

}


Transactional memory …Transactional memory …

An advantage of transactional memory is that it relieves the developer from worrying about synchronization.

Transactional memory can be implemented either in software or hardware. Software transactional memory: Implemented in the software. The compiler

inserts appropriate synchronization code to manage each transaction by examining where statements may run concurrently where specific low level locking is required.

Hardware transactional memory: Uses hardware cache hierarchies and cache coherence protocols to manage and resolve conflicts involving cache data residing in separate processor’s caches.

Bad news: Transactional memory has not been implemented widely. Significant amount of research is being done in this area.


Alternative approaches – OpenMPAlternative approaches – OpenMP

We saw earlier about OpenMP which includes a set of compiler directives. Any code following the compiler directive #pragma omp parallel is identified as a parallel region and is performed by the number of threads equal to the number of processing cores.

Along with directive #pragma omp parallel compiler directive, OpenMP provides the compiler directive #pragma omp critical, which specifies the code region following the directive as a critical section in which only one thread can be active.

Documents

6.1 Silberschatz, Galvin and Gagne 2005 Operating System Concepts Chapter 5: Process Synchronization Background The Critical-Section Problem Petersons