ch06 - Process Syncronization part1.ppt · Operating System Concepts – 8 th Edition 6.6 Silberschatz, Galvin and Gagne ©2009 Process Interaction When several tasks want to obtain

Silberschatz, Galvin and Gagne ©2009Operating System Concepts – 8th Edition,

Process Synchronization

Modified by M.Rebaudengo - 2013

Part I

6.2 Silberschatz, Galvin and Gagne ©2009Operating System Concepts – 8th Edition

ConcurrencyConcurrency is the simultaneous execution of threads

The system must support concurrent execution of threadsScheduling:

Deals with execution of “unrelated” threadsConcurrency:

Deals with execution of “related” threads

Why is it necessary?Cooperation: One thread may need to wait for the result of some operation done by another thread

e.g. “Calculate Average” must wait until all “data reads” are completed

Competition: Several threads may compete for exclusive use of resourcese.g. two threads trying to increment the value in a memory location


Competition and Cooperation

CompetitionProcesses compete for resourcesEach process could exist without the other

CooperationEach process is aware of the otherProcesses SynchronizationExchange information with one another

Share memoryMessage passing


Resources

An object, necessary to a task in order to executeHardware resources:

Co-processorI/O system (e.g., printer, disks)memorynetwork

Software resources:buffer memory spaceportion of code source.


Mutual Exclusion

Critical resource: a resource not shareable for which sharing by the threads must be controlled by the systemCritical section (or critical region) of a program: a part of a program where access to a critical resource occursIf one thread is going to use a shared resource (critical resource)

a filea variableprinterregister, etc

the other thread must be excluded from using the same resource


Process Interaction

When several tasks want to obtain a resource, they enter in competition.Processes unaware of each other

independent processes not working togetherThe OS must resolve the competition for resources

I/O, memory, printer, tape drive, etc.Each process should leave the state of any resource that it uses unaffectedIssues involved:

Mutual exclusion– The resource being competed for is a critical resource– The portion of program in each process that uses the critical

resource is a critical section– At any time, only one program is allowed to be in its critical

section.DeadlockStarvation


Process Interaction (cont.)Processes indirectly aware of each other (cooperation by sharing)

shared access to some objectshared variables, files, or databasesProcesses may use and update the shared data without reference to other process, but know that other processes may have access to the same data.

Issues involvedmaintenance of data integritySince data are stored in resources (devices, memory), the control problems of mutual exclusion, deadlock, and starvation are still present.

– Mutual exclusion applies only to writing, not reading of data.Data coherence

– Example: a = b must be enforced in the following two processes:– P1: a := a + 1;

b := b + 1;P2: b := 2 * b;

a := 2 * a;(Cont.)


Process interaction (cont.)

If the traces of P1 and P2 are as below, a = b is not enforced.1. a := a + 1;2. b := 2 * b;3. b := b + 1;4. a := 2 * a;

The solution is to put the instructions of each process in a critical section.


Process interaction (cont.)

Processes directly aware of each other (cooperation by communication)Interprocess communication exists.Sending and receiving of messages are involved.Issues involved

no shared object, hence no mutual exclusionThe problems of deadlock and starvation are still present.

– deadlock: two processes may be blocked, waiting for a message from the other.

– starvation: three processes are involved in communication, but two of them exchange information repeatedly that the third one waits indefinitely for its turn.


Example: Producer-Consumer Problem

Paradigm for cooperating processesproducer process produces information that is consumed by a consumer process later

Since a producer and a consumer can work at different speeds, abuffer is needed where the producer can temporarily store data thatcan be retrieved by the consumer at a more appropriate speed

An integer count 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 It is decremented by the consumer after it consumes a buffer.

bufferProducer Consumer


Bounded-Buffer

Data shared by the producer and the consumer#define BUFFER_SIZE 10

typedef struct {

. . .

} item;

item buffer[BUFFER_SIZE];

int in = 0;

int out = 0;

Circular Array:in points to the next free position in the bufferout points to the first full position in the buffer


Producer

while (true) {

/* produce an item and put in nextProduced */while (count == BUFFER_SIZE)

; // do nothingbuffer [in] = nextProduced;in = (in + 1) % BUFFER_SIZE;count++;

}

In

out


Consumer

while (true) {while (count == 0)

; // do nothingnextConsumed = buffer[out];out = (out + 1) % BUFFER_SIZE;

count--;

/* consume the item in nextConsumed}

In

out


Race Conditions

A race condition occurs when multiple processes are trying to dosomething with shared data and the final outcome depends on the orderin which the processes run.

When two or more processes/threads are executing concurrently, the result can depend on how the two instruction streams are interleaved.

Race conditions may cause:undesired computation results.bugs which are hard to reproduce!


Race Condition

Race condition: The outcome of concurrent thread execution depends on the particular order in which the access takes place.

count++ could be implemented asregister1 := countregister1 := register1 + 1count := register1

count-- could be implemented asregister2 := countregister2 := register2 - 1count := 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}

To prevent race conditions, concurrent processes must be synchronized.


Critical Section

A section of code, common to n cooperating processes, in which the processes may be accessing common variables, competing to use some shared data

Each process has a code segment, called critical section, in which the shared data is accessed.

Problem – ensure that when one process is executing in its critical section, no other process is allowed to execute in its critical section

A code within a critical section must be executed exclusively by a single process.


Critical-Section Problem

A Critical Section environment contains:

Entry Section: code requesting entry into the critical section.

Critical Section: code in which only one process can execute at any one time.

Exit Section: the end of the critical section, releasing or allowing others in.

Remainder Section: rest of the code after the critical section.

do { entry section

critical section exit section

remainder section } while (TRUE);


Solution to Critical-Section ProblemThe critical section must enforce all 3 of the following rules:

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.

Critical Section

1. only one process

When exiting from CS

2. Pick up a process to enter

3. Delta time exists

When coming and entering CS

Speed and Number of CPUs: No assumption may be made about speeds or number of CPUs.


Concurrency requirements

Among all threads that have CSs for the same resourceOnly one thread at a time is allowed into its CS

It must not be possible for a thread requiring access to a CS to be delayed indefinitely

no deadlockno starvation

When no thread is in a CS, any thread requesting entry to the CS must be granted permission without delayNo assumptions are made about the relative thread speeds or number of processors.A thread remains inside its CS for a finite time only.


Solution 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

do { entry section



do { entry section




Solution to Critical-Section Problem2. 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

do { entry section




Solution to Critical-Section Problem

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


Comments

Deadlock (all processes are blocked) represents a violation of progressStarvation (a process never enters in CS) represents a violation of bounded waiting.


Mutual Exclusion

Need ways to enforce critical sectionsPrevent race conditions that cause errors

Requirements for mutual exclusionSafety (aka mutual exclusion): only one process/thread at a time inside CSLiveness (aka progress): if nobody has access and somebody wants in, somebody gets inNo starvation (aka bounded waiting): if you want in, you will eventually get in

Desirable properties:Efficiency: can get into CS in relatively few instructionsLow load: waiting for CS doesn’t waste resourcesFairness: if you want in, nobody else gets in ahead of you twice (i.e., if two threads are both trying to enter a critical section, they have equal chances of success).


Types of solutions

Software solutionsalgorithms who’s correctness does not rely on any other assumptions

Hardware solutionsrely on some special machine instructions

Operating System solutionsprovide some functions and data structures to the programmer


Software solutions


do {while ( turn ^= i );/* critical section */turn = j;/* remainder section */

} while(TRUE);

Critical section problem

Here’s an example of a simple piece of code containing the components required in a critical section.i is the current process, j the "other" processThe variable turn indicates whose turn it is to enter the critical section.

Entry Section

Critical Section

Exit Section

Remainder Section


Solving the problem

Shared variables: char inside; boolean variableinitially inside = 0

Now ask:Is this Mutual Exclusion? Progress? Bounded waiting?

Code is unsafe: thread 0 could finish the while test when inside is false, but then 1 might check

before thread 0 can set inside to true!

do {

while (inside) continue;inside = true;critical section

inside = false;reminder section

} while (1);

Algorithm 0


Shared Pointer to Active Process Algorithm 1

Shared variables: int turn;initially turn = 0turn = i ⇒ Pi can enter its critical section

Process Pi

do {while (turn != i) ;

critical sectionturn = j;

reminder section} while (1);

Satisfies mutual exclusion, but not progressPi, Pj, Pi, Pj… strict alternation of processesPi leaves, Pj busy with long I/O, Pi comes back to CS-entry;

No one in the CS, but Pi has to wait until Pj to come to the CSWhat if Pj never comes back to CS ?


Boolean Array

FLAG FOR EACH PROCESS GIVES STATE:Each process maintains a flag indicating that it wants to get into the critical section. It checks the flag of the other process and doesn’t enter the critical section if that other process wants to get in.

Are the three Critical Section Requirements Met?

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

} while (1);

Algorithm 2

Shared variablesboolean flag[2];

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


Boolean Array

Satisfies mutual exclusion, but not progress requirement.

Algorithm 2

Pido {

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

} while (1);

Pjdo {

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

} while (1);

Pi: sets flag[i] to truePj: sets flag[j] to trueIndefinite wait: deadlock

Algorithm depends on the exact timing of the two processes


Peterson’s Solution

Two-process solutionAssume that the LOAD and STORE instructions are atomic (they 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!

Algorithm 3


do { flag[i] = TRUE; turn = j; while (flag[j] && turn == j);

critical section flag[i] = FALSE;


Peterson’s Solution: algorithm for Process Pi

Algorithm 3


Prove this algorithm is correct

1. Mutual exclusion is preserved2. The progress requirement is satisfied.3. The bounded waiting requirement is met.



1. Mutual exclusion is preserved




do { flag[j] = TRUE; turn = i; while (flag[i] && turn == i);

critical section flag[j] = FALSE;



Proof of correctness

Mutual exclusion is preserved: P0 and P1 are both in CS

only if – flag[0] = flag[1] = true

and only if – turn = i for each Pi (impossible)



2. Is the progress requirement satisfied ?







Pj stuck at this point



2.1 The progress requirement is satisfied.







flag[i] = false Pj can enter



2.2 Is the progress requirement is satisfied ?









2.2.1 The progress requirement is satisfied.







turn = j Pj can enter



2.2.2 Is the progress requirement is satisfied ?







turn = i Pi can enter



2.2.2.a The progress requirement is satisfied.







flag[i] = false Pj can enter



2.2.3 The progress requirement is satisfied.







turn = j Pj can enter



3. The bounded waiting requirement is met







Pi will enter the CS after at most one entry by Pj


Drawbacks of software solutions

Processes that are requesting to enter in their critical section are busy waiting (consuming processor time needlessly)If CSs are long, it would be more efficient to block processes that are waiting.


Hardware Synchronization



Any solution to the critical-section problem requires a simple tool – a lock.Race conditions are prevented by requiring that critical regions be protected by locks

do { acquire lock

critical section release lock



Solution to Critical-section Problem Using Locks

Lock: prevents someone from doing somethingLock before entering critical section and before accessing shared dataUnlock when leaving, after accessing shared dataWait if locked: all synchronization involves waiting.



Many systems provide hardware support for critical section codeUniprocessors – could disable interrupts

Currently running code would execute without preemptionGenerally too inefficient on multiprocessor systems

Modern machines provide special atomic hardware instructionsAtomic = non-interruptable


Critical Section Access - Disabling Interrupts

One way to provide mutual exclusion is to disable interrupts (and thus context switching), but

It cannot be done for long (or some interrupts will be lost)User processes are not allowed to do thatI/O may be needed while in a critical section (and it will never be completed with interrupts disabled)It disables even time interrupts, thus not allowing preemptionIt does not work in a multi-processor system, anyway!


Interrupt Disabling

If it is guaranteed that no interrupt occurs while a thread is in the CS, then no other thread can enter the same CS

Process Pi:repeatdisable interruptscritical sectionenable interruptsremainder section

forever


Hardware solutions: interrupt disabling

On a uniprocessor: no overlapping of executionTherefore, if a process doesn’t get interrupted in its CS, mutual exclusion is guaranteed.Degrades efficiency because processor cannot interleave threads when interrupts are disabledSimplest solution

but it is not desirable to give a thread the power of controlling interrupts

On a multiprocessor: mutual exclusion is not preservedGenerally not an acceptable solution.


Atomic Read-Write-Modify Instructions

Modern machines provide special atomic hardware instructionsAtomic = non-interruptable

Atomically read old value, write new valueExamples:

Test & Set (most architectures)Exchange (Pentium) Compare & Swap (68K, Sparc)


Hardware lock

The hardware lock is done with a binary flag which indicates if the resourceis free or not

Each task will test the flag before using the resource: if it is already used byanother task, it will do an active wait.


Hardware lock functioning

If the resource is free, the task will set the flag «busy» before using theresource and will set it again «free» after finishing the job with the resource.

It is necessary to have a means to test and set this flag in an indivisible (oratomic) way.

Processors usually have a «TEST and SET» instruction allowing to test andset/reset a memory location in an atomic way.


Atomic Operations

Atomic Operation: an operation that always runs to completion (without interruption) or not at all

It is indivisible: it cannot be stopped in the middle and its state cannot be modified by someone else in the middleFundamental building block – if no atomic operations, then have no way for threads to work together

On most machines, memory references and assignments (i.e. loads and stores) of words are atomic


Test and set

We assume the existence of a shared “lock” variable

int lock = 0; // shared

Will only have two possible values0 meaning nobody is inside the critical section1 meaning somebody has entered the critical section


Test and Set

Atomic operation:Test the value of a flag (lock)

If it is set, leave it (and wait until it is reset by the other).Else set it (as saying "I’ll enter CS")

Example:while ( testAndSet( lock ) == true )

;

// I’ll enter CS.


Test And Set Instruction

Definition:

boolean TestAndSet (boolean *target){

boolean rv = *target;*target = TRUE;return rv:

}

if target ==1 (locked), target stays 1 and return 1, “wait”

if target ==0 (unlocked), set target to 1 (lock door), return 0, and “enter CS”


Shared data: boolean lock = false;// if lock == 0, door open, if lock == 1, door locked

Solution (Mutual-Exclusion):do {

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

// critical sectionlock = FALSE;

// remainder section } while (TRUE);

Solution using TestAndSet


Busy Waiting (“Spinning”)

Busy-Waiting: thread consumes cycles while waiting

void acquire() {while (testset(value)) {}

}

void release() {value = 0;

}

spin-lock


Bounded-waiting Mutual Exclusion with TestandSet()

do { waiting[i] = TRUE; key = TRUE; while (waiting[i] && key)

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

// critical section j = (i + 1) % n; while ((j != i) && !waiting[j])

j = (j + 1) % n; if (j == i)

lock = FALSE; (No one is waiting)else

waiting[j] = FALSE; (process j enters next)// remainder section

} while (TRUE);


Properties of machine instructions

Advantages:Applicable to any number of processesMachine can receive interruptsCan be used on single as well as multiple processor machines sharing main memorySimple and easy to verify

Disadvantages:Busy WaitingStarvationDeadlock.


Busy waiting

Busy waits waste CPU cycles:Generate unnecessary context switchesSlow down the progress of other processes


Priority inversion

A high priority process doing a busy wait may prevent a lower priority process to do its work and leave its critical region.


Starvation is possible

When a process leaves a critical section and more than one process is waiting, the selection of a waiting process is arbitrary. Thus, some process could indefinitely be denied access.


Deadlock is possible

Consider the following scenario on a single-processor system:Process P1 executes the special instruction and enters its critical sectionP1 is then interrupted to give the processor to process P2, which has higher priorityIf P2 now attempts to use the same resource as P1, it will be denied access because of mutual exclusion mechanism. Thus, it will go into a busy waiting loopHowever, P1 will never be dispatched because it is of lower priority than another ready process P2.


Operating System solutions


Semaphores

The hardware-based solutions for the CS problem are complex for application programmers to useTo overcome this difficulty, a synchronization tool, called semaphore, has been proposedProposed by Dijkstra (1965)Semaphores do not require busy waiting Semaphore S – integer variableTwo standard operations modify S:

wait() and signal()Originally called

P(): (from the Dutch probeer te verlagen: “try to decrease”, Wait (Busy wait or sleep) if the resource is not available)V(): (from the Dutch verhogen = to increment, free the resource).

Edsger W. Dijkstra (1930-2002)


Semaphore Definition

A semaphore S is a shared variable (protected by the OS) that can be used by processes to send and receive signals.The following operations apply:

Initialize(S): S has to be initializedWait(S)Signal(S)

OS must guarantee that each of these operations are atomic.It must be impossible for two processes to execute them simultaneously.The assembly language statements that implement these operations will never be interleaved.


SemaphoresCan only be accessed via two atomic operations

wait (S) { while S <= 0

; // no-opS--;

}signal (S) {

S++;}


Types of Semaphores

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 locksCan implement a counting semaphore S as a binary semaphore


Binary SemaphoreInteger value can range only between 0 and 1; can be simpler to implement

Also known as mutex locks as they are locks that provide mutual exclusion.

We can use binary semaphore to deal with the CS problem formultiple processes.The n processes share a semaphore, mutex, initialized to 1

6.74 Silberschatz, Galvin and Gagne ©2009Operating System Concepts – 8th Edition 74

Using semaphores

Semaphores can be used for mutual exclusionSemaphore value initialized to 1Wait on entry to critical sectionSignal on exit from critical section


Semaphores

The semaphore used by railroads indicates whether the train can proceed. When it’s lowered (a), an oncoming train is expected. If it is raised (b), the train can continue.

a) Stop b) All Clear

6.76 Silberschatz, Galvin and Gagne ©2009Operating System Concepts – 8th Edition76

Semaphores

The semaphore concept was taken from railway signalling.

It is used to control the access on a railway section by the trainstraveling one after the other (the railway is a shared resource)

When the train enters a section, the semaphore at the entry blocksis lowered, and the rest of the trains have to wait till the train insidethe section leaves it.


Mutual-Exclusion Implementation with semaphores

Provides mutual exclusion (for Process Pi)Semaphore mutex; // initialized to 1do {

wait (mutex);// Critical Section

signal (mutex);// remainder section

} while (TRUE);


Using Semaphores for Mutex

1 repeat

2 wait(mutex);

3 critical section

4 signal(mutex);

5 remainder section

6 until FALSE

1 repeat

2 wait(mutex);

3 critical section

4 signal(mutex);

5 remainder section

6 until FALSE

semaphore mutex = 1 -- unlocked

Thread A Thread B



semaphore mutex = 0 -- locked

1 repeat

2 wait(mutex);

3 critical section

4 signal(mutex);

5 remainder section

6 until FALSE

1 repeat

2 wait(mutex);

3 critical section

4 signal(mutex);

5 remainder section

6 until FALSE

Thread A Thread B



semaphore mutex = 0 --locked

1 repeat

2 wait(mutex);

3 critical section

4 signal(mutex);

5 remainder section

6 until FALSE

1 repeat

2 wait(mutex);

3 critical section

4 signal(mutex);

5 remainder section

6 until FALSE

Thread A Thread B




1 repeat

2 wait(mutex);

3 critical section

4 signal(mutex);

5 remainder section

6 until FALSE

1 repeat

2 wait(mutex);

3 critical section

4 signal(mutex);

5 remainder section

6 until FALSE

Thread A Thread B




1 repeat

2 wait(mutex);

3 critical section

4 signal(mutex);

5 remainder section

6 until FALSE

1 repeat

2 wait(mutex);

3 critical section

4 signal(mutex);

5 remainder section

6 until FALSE

Thread A Thread B



semaphore mutex = 1 -- unlocked This thread cannow be released!

1 repeat

2 wait(mutex);

3 critical section

4 signal(mutex);

5 remainder section

6 until FALSE

1 repeat

2 wait(mutex);

3 critical section

4 signal(mutex);

5 remainder section

6 until FALSE

Thread A Thread B




1 repeat

2 wait(mutex);

3 critical section

4 signal(mutex);

5 remainder section

6 until FALSE

1 repeat

2 wait(mutex);

3 critical section

4 signal(mutex);

5 remainder section

6 until FALSE

Thread A Thread B


Critical Section for n Processes


Counting semaphore

The concept of semaphore can be extended to the case where ntasks can simultaneously access a resource controlled by thesemaphore

The initial value of the counter S determines the number of taskswhich will be able to cross the semaphore before being blocked(number of tasks which can access simultaneously the criticalsection)

To use a resource, wait()To release a resource, signal()


Sempahore usage

Counting semaphores are often used to control access to a number of similarresources, such as disks, tape drives, CDs, etc.

We may have 8 disks available for allocation to processes and a counting semaphore keeps track of the number remaining to allocate (if any).

A semaphore is typically initialized to the number of resources availableWait() decrements the semaphore; Signal() increments the semaphore. Presumably, if the value of the semaphore is ‘acceptable,’ the process enters its critical section. If count goes to 0, then no more of these resources are available and the requesting process will likely block until the semaphore becomes greater than 0.


Shareable resource – Example

T1 T2

RAM

1

RAM

3

RAM

2Print = 3

Requête RequêteAccès

Request Request

Access


Counting semaphores


Synchronization with Semaphores (I)

We can use semaphores for synchronizing processes in an arbitrary fashionenforcing order of access between two processes

Suppose there are two processes P1 and P2, where P1 contains code C1 and P2 contains code C2Want to ensure that code C1 executes before code C2Use semaphores to synchronize the order of execution of the two processes

Semaphore S=0; // initial value of semaphore = 0

Process P2:

wait(S); // P() the semaphoreC2; // execute C2

Process P1:

C1; // execute C1signal(S); // V() the semaphore


Synchronization with Semaphores (I) (cont.)

In the previous example there are two cases:if P1 executes first, then

C1 will execute first, then P1 will V() the semaphore, increasing its value to 1Later, when P2 executes, it will call wait(S), which will decrement the semaphore to 0 followed by execution of C2Thus C1 executes before C2

If P2 executes first, then P2 will block on the semaphore, which is equal to 0, so that C2 will not be executed yetLater, when P1 executes, it will run through C1, then V() the semaphoreThis awakens P2, which then executes C2Thus C1 executes before C2.


First Thread 1


First Thread 2


Synchronization with Semaphores (II)

proc_A {

while(TRUE) {compute A1;

write(x);

V(s1); //signal proc_Bcompute A2;

// wait for signal from proc_BP(s2);

read(z);

}

}

semaphore s1 = 0;semaphore s2 = 0;

proc_B {

while(TRUE) {// wait for signal from proc_B

P(s1);read(x);compute B1;write(z);V(s2); //signal proc_Acompute B2;

}}

In this case, the semaphore is used to exchange synchronization signals among processes, as opposed to solving the strict critical section problem.

P(s1) will not ExecuteUntil V(s1) sets s1 to 1x Written Before Read

P(s2) will not ExecuteUntil V(s2) sets s2 to 1y Written Before Read


Exercise

2 processes execute concurrently, P1 and P2Part1 in P1 and Part2 in P2 can be done in either orderPart3 in P1 can only be done after Part2 (in P2) is finished.

P1 P2

Part1 Part2

Part3

concurrent

precedes


Solution

P1 P2

Part1 Part2

Part3

concurrent

precedesWait(s)

Signal(s)

If P2 gets the CPU first, the s semaphore will get the value 1.Thus, when P1 gets the CPU it will not be stopped by thewait( ) call.

semaphore s = 0


Three processes P1; P2; P3

semaphores s1 = 1, s2 = 0;

P(s1); P(s2); P(s2);A B CV(s2); V(s2); V(s1);

Which execution orderings of A, B, C, are possible?

Exercise 2

P1 P2 P3


Solution3 processes P1; P2; P3

semaphores s1 = 1, s2 = 0;

P(s1); P(s2); P(s2);A B CV(s2); V(s2); V(s1);

P1 P2 P3

A

B

C


Exercise 3

There are three processes, each produces balls of some color (e.g. Red, Green, Blue)Sequencing required:

Red ball followed by Green followed by Blue and so-on.


Solution

Solution:

Semaphore s1 = 1;Semaphore s2 = 0;Semaphore s3 = 0;

Procedure RED_Generator(){do

{wait(s1);

generate(RedBall);

signal(s2)}

while (true);}

Procedure GREEN_Generator(){do

{wait(s2);

generate(GreenBall);

signal(s3)}

while (true);}

Procedure BLUE_Generator(){do

{wait(s3);

generate(BlueBall);

signal(s1)}while (true);}


Home Work 1

Write the code to guarantee the following graph of precedences

B

A

C


Home Work 2

Write the code to guarantee the following graph of precedences

B

A

C

D


Semaphore ImplementationThe main disadvantage of previous mutual-exclusion solution is the busy waiting (CPU is wasting). This type of semaphore is called a spinlock.To overcome this, we can use the concept of block and wakeup operations.

Typedef struc { int value;struct process *list;

} semaphore


Semaphore Implementation with no Busy waiting

With each semaphore there is an associated waiting queue. Each entry in a waiting queue has two data items:

value (of type integer)pointer to next record in the list

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.



Implementation of wait:wait (semaphore *S) {

S->value--; if (S->value < 0) {

add this process to S->list; block();

} }



Note that the semaphore value may be negative.Its magnitude is the number of processes waiting on that semaphore.The list of waiting processes can be easily implemented by a link field in each process control block (PCB).



Implementation of signal:signal (semaphore *S) {

S->value++; if (S->value <= 0) {

remove a process P from S->list; wakeup(P);

}}


P and V Must Be Indivisible

Semaphore operations must be indivisible, or atomic.Once OS begins either a P or V operation, it cannot be interrupted until it is completed.P operation must be indivisible; otherwise there is no guarantee that two processes won’t try to test P at the “same” time and both find it equal to 1.

P(S): if S > = 1 then S = S – 1else block the process on S queue

Two V operations executed at the same time could unblock two processes, leading to two processes in their critical sections concurrently.

V(S): if some processes are blocked on thequeue for S then unblock a process

else S = S + 1

Semaphores: observations, I.

What does S.count represent?if S.value >=0: the number of processes that can execute wait(S) without being blocked = S.count (not > 1 for mutual exclusion)if S.value<0: the number of processes waiting on S is = |S.value|

Atomicity and mutual exclusion: no 2 process can be in wait(S) or signal(S) (on the same S) at the same time (even with multiple CPUs) the blocks of code defining wait(S) and signal(S) are, in fact, critical sections

The order in which processes are awakened depends on the CPU scheduling algorithm (not always FCFS)

Semaphores: observations, II.

The critical sections defined by wait(S) and signal(S) are very short: typically 10 instructionsSolutions:

uniprocessor: disable interrupts during these operations (i.e., for a very short period). This does not work on a multiprocessor machine.multiprocessor: use previous software or hardware schemes. The amount of busy waiting should be small.


Semaphores

AdvantagesOS guarantees that Wait and Signal are atomicProgrammer does not need to worry about interleaving within the entry and exit sections.No spin locksSemaphores are machine-independentThey are simple but very generalThey work with any number of processesWe can have as many critical regions as we want by assigning a different semaphore to each critical region

OS designer must use the features of the hardware to provide semaphores.


State transition diagram

The state transition diagram for a job in an operating system that provides a semaphore

New state: waiting for a semaphore


Process States

running ready ready_queue

time-out

dispatch

running ready


Process States


time-out

dispatch

ready

blocked

wait(si)

wait-queues

s1 sn. . .

. . .

. . .

running


Process States


time-out

dispatch

ready

blocked

wait(si)

wait-queues

s1 sn. . .

. . .

. . .


Process States


time-out

dispatch

ready

blocked

wait(si)

wait-queues

s1 sn. . .

. . .

. . .

A running process calls signal(si).

running

signal(si)


Process 4Process 3Process 2Process 1

s

SemaphoresThere is a wait-queueassociated with each semaphore.

s

P(s)CS1V(s)

Program1

P(s)CS2V(s)

Program2

P(s)CS3V(s)

Program3

P(s)CS4V(s)

Program4

s = 2



s

Semaphores

P(s)CS1V(s)

Program1

P(s)CS2V(s)

Program2

P(s)CS3V(s)

Program3

P(s)CS4V(s)

Program4

P(s)

s = 1



s

Semaphores

P(s)CS1V(s)

Program1

P(s)CS2V(s)

Program2

P(s)CS3V(s)

Program3

P(s)CS4V(s)

Program4Program2

s = 0



s

Semaphores

P(s)CS1V(s)

Program1

P(s)CS2V(s)

Program2

P(s)CS3V(s)

Program3

P(s)CS4V(s)

Program4 Process 3

s = -1



s

Semaphores

P(s)CS1V(s)

Program1

P(s)CS2V(s)

Program2

P(s)CS3V(s)

Program3

P(s)CS4V(s)

Program4 Process 3

Process 3

Process 4

s = -2



s

Semaphores

P(s)CS1V(s)

Program1

P(s)CS2V(s)

Program2

P(s)CS3V(s)

Program3

P(s)CS4V(s)

Program4 Process 4

s = -1



s

Semaphores

P(s)CS1V(s)

Program1

P(s)CS2V(s)

Program2

P(s)CS3V(s)

Program3

P(s)CS4V(s)

Program4 Process 4

s = 0



s

Semaphores

P(s)CS1V(s)

Program1

P(s)CS2V(s)

Program2

P(s)CS3V(s)

Program3

P(s)CS4V(s)

Program4

s = 1



s

Semaphores

P(s)CS1V(s)

Program1

P(s)CS2V(s)

Program2

P(s)CS3V(s)

Program3

P(s)CS4V(s)

Program4

CS4

s = 2


Deadlock

Semaphores provide synchronization, but can introduce more complicated higher level problems like deadlock

two processes deadlock when each wants a resource that has been locked by the other processe.g. P1 wants resource R2 locked by process P2 with semaphore S2, while P2 wants resource R1 locked by process P1 with semaphore S1


DeadlockDeadlock – two or more processes are waiting indefinitely for an event (a signal operation) that can be caused by only one of the waiting processesLet S and Q be two semaphores initialized to 1

If P0 waits on S and P1 waits on Q, simultaneously, then if P0 waits on Q, it will wait indefinitely for P1 to signal Q

Sequence 1, 2, 3, 4 causes deadlockBut sequence 1, 3, 2, 4 will not deadlock.

P0wait(S);wait(Q);CSsignal(S);signal(Q);

P1wait(Q);wait(S);CS signal(Q);signal(S);

13

24


Deadlock

In the previous example, Each process will sleep on the other process’s semaphorethe signal() signalling statements will never get executed, so there is no way to wake up the two processes from within those two processesthere is no rule prohibiting an application programmer from wait()’ing Q before S, or vice versa - the application programmer won’t have enough information to decide on the proper orderin general, with N processes sharing N semaphores, the potential for deadlock grows.


Setting up a rendezvous (I)

To force two processes to wait for each other, we need two semaphores both initialized at 0

semaphore waitforfirst = 0;semaphore waitforsecond = 0;


Setting up a rendezvous (II)

When the first process is ready, it will doV(&waitforfirst);P(&waitforsecond);

When the second process is ready, it will doV(&waitforsecond);P(&waitforfirst);


Setting up a rendezvous (III)

What will happen if the first process doesP(&waitforsecond);V(&waitforfirst);

and the second process doesP(&waitforfirst);V(&waitforsecond);

We will have a deadlock


Weakness of Semaphores

Semaphores provide a convenient and effective mechanism for process synchronization.However, incorrect use may result in timing errors.

...critical section

...signal(mutex);

signal(mutex);...

critical section...

wait(mutex);

wait(mutex);...

critical section...

wait(mutex);

wait(mutex);...

critical section...

incorrect order(not mutual exclusive)

typing error(deadlock)

forgotten


StarvationStarvation – indefinite blocking. A process may never be removed from the semaphore queue in which it is suspended:

if the waiting queues are implemented in LIFO order.


Implementation of semaphores

Any software schemes, such as Peterson’s algorithm, can be used to implement semaphores. However, the busy-waiting in each of them imposes a large overhead.

Recall that the Peterson’s algorithm discussed above involves only two processes. Generalizing this algorithm for n processes to implement general semaphores has a large overhead.

Hardware implementation based ontest and set instruction

the busy-waiting in the V() and P() operations are relatively short

disabling interruptsthere is no wait loop, but this approach works only on a single processor system.


Semaphores with interrupt disabling

Signal(semaphore sem)DISABLE_INTS

sem.val++if (sem.val <= 0) {

th = remove nextthread from sem.L

wakeup(thread)}

ENABLE_INTS

struct semaphore {int val;list L;

}

Wait(semaphore sem)DISABLE_INTS

sem.val--if (sem.val < 0){

add thread to sem.Lsleep(thread)

}ENABLE_INTS


type semaphore = recordvalue, flag: integer; L: list of process;

end;

0

wait(S):repeat until test-and-set(S.flag)

if (S.value == 0) { add this process to S.L; sleep & S.flag=0;}

else{

S.value = 0; S.flag=0;}

Implementing a binary semaphore by TAS

signal(S):repeat until test-and-set(S.flag)if (queue is not empty){wakeup(); /* change its state from blocked to

ready; */}

else S.value = 1; S.flag=0


type semaphore = recordvalue, flag: integer; L: list of process;

end;

-3

wait(S):repeat until test-and-set(S.flag)

S.value--;if (S.value <= 0) {

add this process to S.L; sleep & S.flag=0;}

else S.flag=0

Implementing a counting semaphore by TAS

signal(S):repeat until test-and-set(S.flag)

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

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

S.flag=0


Implementing a counting semaphore from binary semaphores: (Barz 1983, Hsieh 1989)

wait(S):wait(S2);wait(S1);S.value--;if (S.value>0) then

signal(S2);signal(S1);

signal(S):wait(S1);S.value++;if(S.value == 1) {

signal(S2); }signal(S1);

binary-semaphore S1=1, S2 = 1, value=k

Documents

ch06 - Process Syncronization part1.ppt · Operating System Concepts – 8 th Edition 6.6 Silberschatz, Galvin and Gagne ©2009 Process Interaction When several tasks want to obtain