Chapter 6: Process Synchronization. 6.2Operating System Concepts Chapter 6: Process Synchronization...

Chapter 6: Process SynchronizationChapter 6: Process Synchronization

6.2Operating System Concepts

Chapter 6: Process SynchronizationChapter 6: Process Synchronization

Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Mutex Locks Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Alternative Approaches X

XX


6.1 Background6.1 Background Processes can execute concurrently

May be interrupted at any time, partially completing execution

Concurrent access to shared data may result in data inconsistency

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

x=0;Thread 1:{for( i=0;i<10;i++)x=x+1;}Thread 2:{for( j=0;j<10;j++)x=x-1;}

x


Illustration of the problemIllustration of the problem Suppose that we wanted to provide a solution to

the consumer-producer problem that fills all the buffers.

We can do so by having an integer counter that keeps track of the number of full buffers.

Initially, counter 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-Consumer problemProducer-Consumer problem

producer process produces information that is consumed by a consumer process

producer: need to care buffer full

consumer: need to care buffer empty

p.257


Producer 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++;

}

Buffer is full ?

item nextProduced;while (true) { /* Produce an item */

while (((in + 1) % BUFFER SIZE count) == out) ; /* do nothing -- no free buffers */ buffer[in] = item; in = (in + 1) % BUFFER SIZE;

}

p.258


ConsumerConsumer

while (1)

{

while (count == 0)

; // do nothing

nextConsumed = buffer[out];

out = (out + 1) % BUFFER_SIZE;

count--;

/* consume the item in nextConsumed

}

Buffer is empty?

while (true) {

while (in == out)

; // do nothing -- nothing to consume

// remove an item from the buffer

item = buffer[out];

out = (out + 1) % BUFFER SIZE;

return item;

}

p.258


SynchronizationSynchronization integer count that keeps track of the number of full buffers

count++ could be implemented as

register = count

register = register + 1

count = register

initial count = 5

p.258

Machine Language


AsynchronizationAsynchronization 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:

T0: producer execute register1 = count {register1 = 5}T1: producer execute register1 = register1 + 1 {register1 = 6} T2: consumer execute register2 = count {register2 = 5} T3: consumer execute register2 = register2 – 1 {register2 = 4} T4: producer execute count = register1 {count = 6 } T5: consumer execute count = register2 {count = 4}

=> data inconsistency

p.259

Machine cycle


Race ConditionRace Condition

Several processes access and manipulate the same data concurrently and outcome of the execution depends on the particular order in which the access takes place

To guard against the race condition, we need to ensure that processes be synchronized

p.259


6.2 Critical-Section Problem6.2 Critical-Section Problem

Consider system of n processes {p0, p1, … pn-1}

Each process has critical section segment of code

Process may be changing common variables, updating table, writing file, etc

When one process in critical section, no other may be in its critical section

p.259


Critical SectionCritical Section

Critical section problem is to design protocol to solve this

Each process must ask permission to enter critical section in entry section, may follow critical section with exit section, then remainder section

General structure of process pi is

p.260


Solution to Critical-Section ProblemSolution to Critical-Section 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 the selection of the processes 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

Assume that each process executes at a nonzero speed

No assumption concerning relative speed of the N processes

p.260


Kernel developerKernel developer preemptive kernel (Solaris, IRIX, Linux 2.6 later)

kernel allows a process to be preemptived while it is running in kernel-mode (need to care race condition)

nonpreemptive kernel (Windows 2000,XP, Linux)

kernel does not allows a process to be preemptive unless

kernel-mode process exits

kernel-mode process blocks

voluntarily yields control of the CPU

We prefer preemptive kernel

suitable for real-time programming

more responsive

p.261


6.3 Peterson’s Solution6.3 Peterson’s Solution

Good algorithmic description of solving the problem Two process solution Assume that the LOAD and STORE instructions are

atomic; that is, cannot be interrupted. 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!

p.261


Algorithm for Process Algorithm for Process PPii

do {

flag[ i ] = TRUE;

turn = j;

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

CRITICAL SECTION

flag[ i ] = FALSE;

REMAINDER SECTION

} while (TRUE);

Provable that 1.Mutual exclusion is preserved2.Progress requirement is satisfied3.Bounded-waiting requirement is met

p.262


Algorithm for Process Algorithm for Process PPii

Satisfies all three requirements

t1 t2 t3 t4

P1

requestingP0 requesting P1 exiting P1 requesting

flag[0] False True True True

flag[1] True True False True

turn 0 1 1 0

CRITICAL SECTION

P1 Entering P0 Waiting

P1 Entering

=> Mutual Exclusion

P0 Waiting P0 Entering => Progress

P1 Waiting =>Bounded waiting

do { flag[ 0] = TRUE; turn =1; while ( flag[ 1 ] && turn ==1 );

CRITICAL SECTION

flag[ 0 ] = FALSE;

REMAINDER SECTION

} while (TRUE);

do { flag[ 1 ] = TRUE; turn =0; while ( flag[0 ] && turn ==0);

CRITICAL SECTION

flag[ 1 ] = FALSE;

REMAINDER SECTION

} while (TRUE);

PP00PP11

補充


6.4 Synchronization Hardware6.4 Synchronization Hardware Many systems provide hardware support for critical section code

All solutions below based on idea of locking

Protecting critical regions via locks

Uni-processors – could disable interrupts

Currently running code would execute without preemption

Disable interrupts is generally too inefficient on multiprocessor systems

Operating systems using this not broadly scalable

p.263

X


Special atomic hardware instructionsSpecial atomic hardware instructions

Modern machines provide special atomic hardware instructions

Atomically = one uninterruptable unit

Either test memory word and set value

Or swap contents of two memory words

p.263


TestAndndSet Instruction TestAndndSet Instruction

Test and modify the content of a word atomically Definition:

boolean TestAndSet (boolean *target)

{

boolean rv = *target;

*target = TRUE;

return rv:

}

p.264


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

p.264


Solution using TestAndSetSolution using TestAndSet

t1 t2 t3 t4

P1

requestingP0 requesting P1

exitingP1 requesting

TestandSet False True True False

Lock True True False True

CRITICAL SECTION


P1 Entering

=> Mutual Exclusion

P0 Waiting

P1 may be Entering

P0 Waiting

=> X progress

X Bounded waiting

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

// critical section

lock = FALSE;


} while ( TRUE);

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

// critical section

lock = FALSE;


} while ( TRUE);

PP11

補充


compare_and_swap Instructioncompare_and_swap Instruction

Definition:int compare and swap(int *value, int expected, int new value) {

int temp = *value;

if (*value == expected)

*value = new value;

return temp;

}

p.264


Solution using compare_and_swapSolution using compare_and_swap

Shared Boolean variable lock initialized to FALSE Solution:

do { while (compare and swap(&lock, 0, 1) != 0)

; /* do nothing */

/* critical section */

lock = 0;

/* remainder section */

} while (true);

p.265


Solution using Solution using compare_and_swapcompare_and_swap

t1 t2 t3 t4

P1 requesting P0 requesting P1 exiting P1 requesting

lock 0 -> 1 1 1 -> 0 0 -> 1

CRITICAL SECTION


P1 Entering

=> Mutual Exclusion

P0 Waiting P1 may be Entering

P0 Waiting

=> X progress

X Bounded waiting

do { while (compare and swap(&lock, 0, 1) != 0) ; /* do nothing */ /* critical section */ lock = 0; /* remainder section */ } while (true);

PP00 do { while (compare and swap(&lock, 0, 1) != 0) ; /* do nothing */ /* critical section */ lock = 0; /* remainder section */ } while (true);

PP11

補充


Satisfies three requirementsSatisfies three requirements Shared variable:

boolean waiting[n], lock; (initially all false) 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)

lock = false;else

waiting [ j ] = false;// remainder section

} while(1)

Complicated for application programmer

p.265


Satisfies three requirementsSatisfies three requirements

t1 t2 t3 t4

P1 requesting P0 requesting P1 exiting P1 requesting

waiting[ 0 ] False ->True False False

waiting[ 1 ] -> True

-> False

False True True

Key T-> F -> T -> T T -> T

Lock True True True ->False True

j 0

CRITICAL SECTION


P1 Entering

=> Mutual Exclusion

P0 Entering => Progress

P1 Waiting =>Bounded waiting

補充


6.5 Mutex Locks6.5 Mutex Locks

Previous solutions are complicated and generally inaccessible to application programmers

OS designers build software tools to solve critical section problem

Simplest is mutex lock

p.266


Product critical regions with it by first acquire() a lock then release() it

do {

acquire lock

critical section

release lock

remainder section

} while (true);

acquire() and release()acquire() and release()

p.266


Calls to acquire() and release() must be atomic Usually implemented via hardware atomic instructions Boolean variable available indicating if lock is available

or not

acquire() { while (!available)

; /* busy wait */

available = false;

}

release() {

available = true;

}

acquire() and release()acquire() and release()

p.267


SpinlockSpinlock

But this solution requires busy waiting This lock therefore called a spinlock

Disadvantage:

busy waiting wastes CPU cycles(Signal-Processor)

Advantage:

No context switch is required when a process spinlock (Multi-Processor)

p.267

P1 P2 P3 P4 P1 P2 P3 P4 P1 P2 P3 P4

busy waiting busy waiting busy waiting

P3 busy waiting P4 busy waiting

P1 Running P2 busy waiting


6.6 Semaphore6.6 Semaphore Synchronization tool Less complicated Semaphore S – integer variable Two standard operations modify S: wait() and signal()

Originally called P( ) and V( ) Can only be accessed via two indivisible (atomic) operations

wait (S) {

while (S <= 0)

; // busy wait

S--;

} signal (S) {

S++;

}

p.267


6.6.1 Usage6.6.1 Usage

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

Then a mutex locks

p.268


Critical-section of Critical-section of n n processesprocesses Binary semaphores to deal with the critical-section

problem for multiple processes

Mutual-exclusion implement with semaphores

Shared variables:

semaphore mutex =1;

Process P1 Process P2

p.268


Control ResourceControl Resource Counting semaphores can be to control access to a

given resource consisting of a finite number of instances.

The semaphore is initialized to the number of resources available.

Each process that wishes to use a resource performs a wait( )

When a process releases a resources, it performs a signal( )

p.268


Synchronization ProblemsSynchronization Problems Can solve various synchronization problems

Consider P1 and P2 that require S1 to happen before S2

S1

S2

S1

S2

P1

P1

P1

P1

P2

P2

P2

p.268


6.6. 2 Semaphore Implementation with no Busy waiting 6.6. 2 Semaphore Implementation with no Busy waiting

Two operations:

block – place the process invoking the operation on the appropriate waiting queue.

wakeup – remove one of processes in the waiting queue and place it in the ready queue.

Each entry in a waiting queue has two data items:

value (of type integer)

pointer to next record in the list

p.269


Semaphore Implementation with no Busy waitingSemaphore Implementation with no Busy waiting (Cont.)(Cont.) Implementation of semaphores

Implementation of wait:

Implementation of signal:

wait (S) { while S <= 0

; // no-op S--; }

signal (S) { S++; }

p.269


Interrupt for Critical-SectionInterrupt for Critical-Section wait( ), signal( ) => share Semaphore S => critical-section

problem

A single-processor environment:

We can inhibiting interrupts during the time the wait( ) and signal( ) operations are executing

A multiprocessor environment:

disabling interrupts on every processor can be difficult task and furthermore can seriously diminish performance

SMP systems must provide spinlocks to ensure that wait( ) and signal( ) preformed atomically

We have limited busy waiting to the critical sections of the wait( ) and signal( ), and these sections are short.

p.270


6.6.3 Deadlock and Starvation6.6.3 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.

(1) S=S-1=0 (2)Q=Q-1=0

p.271


6.6.4 Priority Inversion6.6.4 Priority Inversion

Scheduling problem when lower-priority process holds a lock needed by higher-priority process Solved via priority-inheritance

protocol

p.271


6.7 Classical Problems of Synchronization6.7 Classical Problems of Synchronization

Bounded-Buffer Problem

Readers and Writers Problem

Dining-Philosophers Problem

p.273


6.7.1 Bounded-Buffer Problem6.7.1 Bounded-Buffer Problem

n buffers, each can hold one item

Semaphore mutex initialized to the value 1

Semaphore empty initialized to the value n

Semaphore full initialized to the value 0

p.273


Bounded-Buffer ProblemBounded-Buffer Problem

t1 t2 t3 t4 t5

C requesting P requesting P exiting C Wakeup C exiting

full =0 0 0 1 0 0

empty=n n n-1 n-1 n-1 n

mutex =1 1 0 1 0 1

buffer C Waiting P Entering C Wakeup

p.273


6.7.2 Readers-Writers Problem6.7.2 Readers-Writers Problem

A database is to be shared among several concurrent processes

Readers – only read the database; 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.

p.274


Readers-Writers ProblemReaders-Writers Problem

Reader first:

No reader will be kept waiting unless a writer has already obtained permission to use the shared object

Writer first:

once a writer is ready, that writer performs its write as soon as possible

the solution to either problem may result in starvation

p.274


Starvation–free Solution to the Readers-Writers Problem

Reader first – Shared Data

Semaphore rw_mutex initialized to 1.

Semaphore mutex initialized to 1.

Integer read_count initialized to 0.

do {wait(mutex); read_count++; if (read_count == 1) wait(rw_mutex); signal(mutex); .../* reading is performed */ ...wait(mutex); read_count--; if (read_count == 0) signal(rw_mutex); signal(mutex); } while (true);

Readers-Writers ProblemReaders-Writers Problem

p.275

do { wait(rw_mutex); ... /* writing is performed */ ... signal(rw_mutex); } while (true);


Reader-Writer LocksReader-Writer Locks

some system provide reader-writer locks

read mode : a process only wishes to read shared data

Multiple processes are permitted on concurrently

write mode : a process wishing to modify the shared data

Only one process may acquire the lock

most useful in following situation :

In applications where it is easy to identify which processes only read shared data and which processes only write shared data

In applications that have more readers than writers.

reader-writer locks generally require more overhead to establish than semaphores or mutual exclusion locks

p.276


6.7.3 Dining-Philosophers Problem6.7.3 Dining-Philosophers Problem

Shared data

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

p.276


Dining-Philosophers ProblemDining-Philosophers Problem The structure of Philosopher i:

Could create a deadlock

p.277


Some SolutionSome Solution

Allow at most four philosophers to be sitting simultaneously at the table

Allow a philosopher to pick up her chopsticks only if both chopsticks are available

to do this she must pick then up in a critical section

Use an asymmetric solution;

an odd philosopher picks up her left chopstick and then her right chopstick

an even philosopher pick up her right chopstick and then her left chopstick

p.277


6.8 Monitors6.8 Monitors Uncorrected use of semaphore operations:

a process interchanges the order in which the wait( ) and signal( ) operations on the semaphore mutex are executed

signal (mutex) …. wait (mutex)

– violating the mutual-exclusion requirement

a process replace signal( ) with wait( )

wait (mutex) … wait (mutex)

– in this case, a deadlock will occur

Omitting of wait (mutex) or signal (mutex) (or both)

either mutual-exclusion is violated or a deadlock will occur

Monitor : high-level language constructs


MonitorsMonitors A high-level abstraction that provides a convenient and effective

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

monitor monitor-name

{

// shared variable declarations

procedure P1 (…) { …. }

…

procedure Pn (…) {……}

Initialization code ( ….) { … }

…

}

}


Schematic view of a MonitorSchematic view of a Monitor


Condition VariablesCondition Variables The monitor construct ensures that only one process at a

time can be active within the monitor

The monitor is not sufficiently powerful for modeling some synchronization schemes. Additional synchronization mechanism (condition construct)

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 ( ). If no process is suspended, then the signal( ) operation has no effect.


Monitor with Condition VariablesMonitor with Condition Variables


Exclusive executionExclusive execution Signal and wait

P either waits until Q leaves the monitor or waits for another condition.

Signal and continue

Q either waits until P leaves the monitor or waits for another condition.

Concurrent Pascal

When thread P executes the signal operation. it immediately leaves the monitor


Solution to Dining PhilosophersSolution to Dining Philosophers

monitor DP

{

enum { THINKING; HUNGRY, EATING) state [5] ;

condition self [5];

void pickup (int i) {

state[i] = HUNGRY;

test(i);

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

}

void test (int i) {

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

(state[i] == HUNGRY) &&

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

state[i] = EATING ;

self[i].signal () ;

}

}

initialization_code() {

for (int i = 0; i < 5; i++)

state[i] = THINKING;

}

}


Dining-Philosopher using MonitorDining-Philosopher using Monitor

Philosopher i must invoke the operations pickup(i) and putdown(i) in the following sequence:


Implementing a Monitor Using SemaphoresImplementing a Monitor Using Semaphores

The monitor mechanism use semaphores semaphore mutex =1, next =0; integer variable next_count =0;

The monitor construct ensures that only one process at a time can be active within the monitor

wait(mutex)

...

body of F

...

if (next_count > 0)

signal(next);

else

signal(mutex);


Condition variable implementCondition variable implement For each condition x, we introduce a semaphore

semaphore x_sem =0;

integer variable x_count =0;

The x.wait( ) and x.signal( ) are implemented as

x.wait( )x_count ++;if (next_count > 0)

signal(next);else

signal(mutex);wait(x_sem);x_count --;

x.signal( )if (x_count > 0){

next_count ++;signal(x_sem);wait(next);next_count --;

}


Resuming Processes within a MonitorResuming Processes within a Monitor

When x.signal( ) is executed, which suspended processes should be resumed next?

FCFS ordering

Conditional-wait

x.wait(c), where c is an integer value (priority number)

the smallest associated priority number is resumed next


Allocate a single resourceAllocate a single resource

monitor ResourceAllocator

{

boolean busy;

condition x;

void acquire(int time) {

if (busy)

x.wait(time);

busy = TRUE;

}

void release( ) {

busy = FALSE;

x.signal( );

}

initialization code( ) {

busy = FALSE;

}

}

R.acquire(t);

...

access the resource;

...

R.release( );


Monitor cannot guaranteeMonitor cannot guarantee

A process might access a resource without first gaining access permission to the resource.

A process might never release a resource once it has been granted access the resource.

A process might attempt to release a resource that it never requested.

A process might request the same resource twice (without first releasing the resource)


6.9 Synchronization Examples6.9 Synchronization Examples

Solaris

Windows XP

Linux

Pthreads


Solaris SynchronizationSolaris Synchronization

Implements a variety of locks to support multitasking, multithreading (including real-time threads), and multiprocessing

adaptive mutexes

for efficiency when protecting data from short code segments

condition variables, readers-writers locks, semaphores

when longer sections of code need access to data

turnstiles

to order the list of threads waiting to acquire either an adaptive mutex or reader-writer lock


Adaptive mutexAdaptive mutex Adaptive mutex starts as a standard semaphore

implemented as a spinlock

Multiprocessor system

if the lock is held by a thread that is currently running on another CPU the thread spinlock➡

if the thread holding the lock is not currently in run state the thread blocks➡

Single-processor system

thread always block rather than spin

protect data that are accessed by short code segment


Condition VariableCondition Variable

condition variable and semaphore are used for these longer code segments

If the desired lock is already held, the thread issues a wait and sleeps

When a thread frees the 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 is less than the cost of waiting in a spinlock


Reader-writer locksReader-writer locks Reader-writer locks are used to protect data that are

accessed frequently but are usually accessed in a read-only manner

Reader-writer locks are more efficient than semaphore

Multiple threads can read data concurrently in reader-writer locks

semaphores always serialize access to the data

Reader-writer locks are relatively expensive to implement, so they are used on long section of code


TurnstileTurnstile A turnstile is a queue structure containing thread

blocked on a lock

turnstile order the list of threads waiting to acquire either adaptive mutex or reader-writer lock

when the lock is released, the kernel selects a thread from the turnstile as the next owner of the lock

Solaris gives each kernel thread its own turnstile rather than associating a turnstile with each synchronized object.

Turnstiles are organized according to a priorityinheritance protocol


Windows XP SynchronizationWindows XP Synchronization

Uses interrupt masks to protect access to global resources on uniprocessor systems

Uses spinlocks on multiprocessor systems

Also provides dispatcher objects which may act as either mutexes and semaphores

Dispatcher objects may also provide events

An event acts much like a condition variable


Linux SynchronizationLinux Synchronization

Linux:

disables interrupts to implement short critical sections

Linux provides:

semaphores

spin locks


Pthreads SynchronizationPthreads Synchronization

Pthreads API is OS-independent

It provides:

mutex locks

condition variables

Non-portable extensions include:

read-write locks

spin locks

End of Chapter 6End of Chapter 6

Chapter 6: Process Synchronization. 6.2Operating System Concepts Chapter 6: Process Synchronization...

Documents

Transcript of Chapter 6: Process Synchronization. 6.2Operating System Concepts Chapter 6: Process Synchronization...