Process Synchronization Continued 7.2 Critical-Section Problem 7.3 Synchronization Hardware 7.4...
-
Upload
blanche-cobb -
Category
Documents
-
view
236 -
download
3
Transcript of Process Synchronization Continued 7.2 Critical-Section Problem 7.3 Synchronization Hardware 7.4...
Process SynchronizationContinued
7.2 Critical-Section Problem7.3 Synchronization Hardware7.4 Semaphores
Critical section
When a process executes code that manipulates shared data (or resource), we say that the process is in a critical section (CS) for that resource
repeat entry section critical section exit section remainder sectionforever
Three Key Requirements for a Valid Solution to the Critical Section Problem
Mutual Exclusion: At any time, at most one process can be executing critical section (CS) code
Progress: If no process is in its CS and there are one or more processes that wish to enter their CS, it must be possible for those processes to negotiate who will proceed next into CS• No deadlock• no process in its remainder section can participate in this
decision Bounded Waiting: After a process P has made a request
to enter its CS, there is a limit on the number of times that the other processes are allowed to enter their CS, before P’s request is granted • Deterministic algorithm, otherwise the process could suffer
from starvation
turn := 0;Process P0:repeat while(turn!=0){}; CS turn:=1; RSforever
Process P1:repeat while(turn!=1){}; CS turn:=0; RSforever
Faulty Algorithm 1 – Turn taking
ok for mutual exclusion, but processes MUST strictly alternate turns
flag[0]:=false;Process P0:repeat flag[0]:=true; while(flag[1]){}; CS flag[0]:=false; RSforever
flag[1]:=false;Process P1:repeat flag[1]:=true; while(flag[0]){}; CS flag[1]:=false; RSforever
Faulty Algorithm 2 - ready flag
Mutual exlusion ok, but not progress
(interleaving flag[1]:=true and flag[0]:=true means neither can enter CS)
flag[0],flag[1]:=falseturn := 0;Process P0:repeat flag[0]:=true; // 0 wants in turn:= 1; // 0 gives a chance to 1 while (flag[1]&turn=1); CS flag[0]:=false; // 0 is done RSforever
Process P1:repeat flag[1]:=true; // 1 wants in turn:=0; // 1 gives a chance to 0 while (flag[0]&turn=0); CS flag[1]:=false; // 1 is done RSforever
Peterson’s algorithm – proved to be correct
Turn can only be 0 or 1 even if both flags are set to true
Peterson’s Algorithm
N-Process Solution: Bakery Algorithm
“Take a number for better service...” Before entering the CS, each Pi takes a
number. Holder of smallest number enters CS next
• ..but more than one process can get the same number
If Pi and Pj receive same number:
• lowest numbered process is served first Process resets its number to 0 in the exit
section
Bakery Algorithm
Shared data:
• choosing: array[0..n-1] of boolean;
initialized to false
• number: array[0..n-1] of integer;
initialized to 0
Bakery Algorithm
Process Pi:repeat choosing[i]:=true; number[i]:=max(number[0]..number[n-1])+1; choosing[i]:=false; for j:=0 to n-1 do { while (choosing[j]); while (number[j]!=0 and (number[j],j)<(number[i],i)); } CS number[i]:=0; RSforever
Important Observation about Process Interleaving
Even a simple high level language assignment statement can be interleaved
One HLL statement
A := B;
Two Machine instructions:
load R1, B
store R1, A
This is why it is possible to two processes to “take” the same number
Bakery Algorithm: Proof
Mutual Exclusion:• If Pi is in CS and Pk has already chosen its
number, then (number[i],i) < (number[k],k) If they both had their numbers before the
decision, this must be true or Pi would not have been chosen
If Pi entered its CS before Pk got its number, Pk got a bigger number
So Pk cannot enter its CS until Pi exits.
Progress, Bounded Waiting:• Processes enter CS in FCFS order
Drawbacks of Software Solutions
Complicated to program Busy waiting (wasted CPU cycles) It would be more efficient to block
processes that are waiting (just as if they had requested I/O).• This suggests implementing the
permission/waiting function in the Operating System
But first, let’s look at some hardware approaches (7.3 Synchronization Hardware):
Hardware Solution 1: Disable Interrupts
On a uniprocessor, mutual exclusion is preserved: while in CS, nothing else can run
• because preemption impossible On a multiprocessor: mutual exclusion is not achieved
• Interrupts are “per-CPU” Generally not a practical solution for user programs But could be used inside an OS
Process Pi:repeat disable interrupts critical section enable interrupts remainder sectionforever
Hardware Solution 2: Special Machine Instructions
Normally, the memory system restricts access to any particular memory word to one CPU at a time
Useful extension: • machine instructions that perform 2 actions atomically on
the same memory location (ex: testing and writing) The execution of such an instruction is mutually
exclusive on that location (even with multiple CPUs) These instructions can be used to provide mutual
exclusion • but need more complex algorithms for satisfying the
requirements of progress and bounded waiting
The Test-and-Set Instruction
Test-and-Set expressed in “C”:
An algorithm that uses testset for Mutual Exclusion:
Shared variable lock is initialized to 0
Only the first Pi who sets lock enters CS
int testset(int &i){ int rv; rv = *i; *i = 1; return rv;}
Process Pi:repeat while(testset(&lock)); CS lock:=0; RSforever
Non Interruptible (atomic)!One instruction reads thenwrites the same memory location
Test-and-Set Instruction
Mutual exclusion is assured: if Pi enters CS, the other Pj are busy waiting
Satisfies progress requirement When Pi exits CS, the selection of the next Pj to
enter CS is arbitrary: no bounded waiting (it’s a race!). • Starvation is possible.
• See Fig 7.10 for (complicated) solution Some processors (ex: Pentium) provide an atomic
Swap(a,b) instruction that swaps the content of a and b.• (Same drawbacks as Test-and-Set)
Using Swap for Mutual Exclusion
Shared variable lock is initialized to 0
Each Pi has a local variable key
The only Pi that can enter CS is the one which finds lock=0
This Pi excludes all other Pj by setting lock to 1• (Same effect as test-
and-set)
Process Pi:repeat key:=1 repeat swap(lock,key) until key=0; CS lock:=0; RSforever
Operating Systems or Programming Language Support for Concurrency
Solutions based on machine instructions such as test and set involve tricky coding.
We can build better solutions by providing synchronization mechanisms in the Operating System or Programming Language (7.4 – Semaphores).
(This leaves the really tricky code to systems programmers)
Semaphores
A Semaphore S is an integer variable that, apart from initialization, can only be accessed through 2 atomic and mutually exclusive operations:
• wait(S) sometimes called P()
• Dutch proberen: “to test”
• signal(S) sometimes called V()
• Dutch verhogen: “to increment”
Busy Waiting Semaphores
The simplest way to implement semaphores.
Useful when critical sections last for a short time, or we have lots of CPUs.
S initialized to positive value (to allow someone in at the beginning).
wait(S): while S<=0 do ; S--;
signal(S): S++;
Atomicity in Semaphores
The test-and-decrement sequence in wait must be atomic, but not the loop.
Signal is atomic. No two processes can
be allowed to execute atomic sections simultaneously.
This can be implemented by other mechanisms (in the OS)
• test-and-set, or
• disable interrupts.
wait(S):
S <= 0
atomic
S - -
F
T
Using semaphores for solving critical section problems
For n processes Initialize semaphore
“mutex” to 1 Then only one process
is allowed into CS (mutual exclusion)
To allow k processes into CS at a time, simply initialize mutex to k
Process Pi:repeat wait(mutex); CS signal(mutex); RSforever
Process Pi:repeat
wait(mutex); CS
signal(mutex); RSforever
Process Pj:repeat wait(mutex); CS signal(mutex); RSforever
Initialize mutex to 1
Semaphores in Action
Synchronizing Processes using Semaphores
Two processes: • P1 and P2
Statement S1 in P1 needs to be performed before statement S2 in P2
We want a way to make P2 wait
• until P1 tells it it is OK to proceed
Define a semaphore “synch” • Initialize synch to 0
Put this in P2: wait(synch); S2;
And this in in P1:
S1;
signal(synch);
Busy-Waiting Semaphores: Observations When S>0:
• the number of processes that can execute wait(S) without being blocked = S
When S=0: one or more processes are waiting on S
Semaphore is never negative When S becomes >0, the first process that
tests S enters enters its CS • random selection (a race)• fails bounded waiting condition