Process Synchronization - Uni Koblenz-Landauunikorn/lehre/... · code to enter a critical section...
Transcript of Process Synchronization - Uni Koblenz-Landauunikorn/lehre/... · code to enter a critical section...
Process Synchronization
Outlook
Motivation Critical Sections Dekker’s Algorithm Dekker s Algorithm Peterson’s Algorithm
Synchronization Hardware Synchronization Hardware Semaphores Classic Synchronization Problems Monitors Synchronization Examples Atomic Transactions Atomic Transactions
2
Motivation
A Classical Synchronization Problemy
0 SIZE-1counter
buffer
out in
Control Flow 1: Producer
while(true) {
Control Flow 2: Consumer
while(true) {( ) {Item item = produce();while(count = SIZE) { }buffer[in] = item;
( ) {while(count = 0) { }Item item = buffer[out];out = (out + 1) % SIZE;buffer[in] item;
in = (in + 1) % SIZE;count++;
}
out (out + 1) % SIZE;count--;consume(item);
}} }
4
Is this Solution Correct?
Producer: count++ Consumer: count--
load r1, countinc r1
load r2, countdec r2inc r1
store r1, countdec r2store r2, count
5
Is this Solution Correct?
Producer: count++ Consumer: count--
load r1, countinc r1
load r2, countdec r2inc r1
store r1, countdec r2store r2, count
Time Control Flow Command r1 r2 count
1
2
33
4
55
66
Is this Solution Correct?
Producer: count++ Consumer: count--
load r1, countinc r1
load r2, countdec r2inc r1
store r1, countdec r2store r2, count
Time Control Flow Command r1 r2 count
1 Producer load r1, count 5 - 5
2
33
4
55
67
Is this Solution Correct?
Producer: count++ Consumer: count--
load r1, countinc r1
load r2, countdec r2inc r1
store r1, countdec r2store r2, count
Time Control Flow Command r1 r2 count
1 Producer load r1, count 5 - 5
2 Producer inc r1 6 - 5
33
4
55
68
Is this Solution Correct?
Producer: count++ Consumer: count--
load r1, countinc r1
load r2, countdec r2inc r1
store r1, countdec r2store r2, count
Time Control Flow Command r1 r2 count
1 Producer load r1, count 5 - 5
2 Producer inc r1 6 - 5
3 Consumer load r2 count 6 5 53 Consumer load r2, count 6 5 5
4
55
69
Is this Solution Correct?
Producer: count++ Consumer: count--
load r1, countinc r1
load r2, countdec r2inc r1
store r1, countdec r2store r2, count
Time Control Flow Command r1 r2 count
1 Producer load r1, count 5 - 5
2 Producer inc r1 6 - 5
3 Consumer load r2 count 6 5 53 Consumer load r2, count 6 5 5
4 Consumer dec r2 6 4 5
55
610
Is this Solution Correct?
Producer: count++ Consumer: count--
load r1, countinc r1
load r2, countdec r2inc r1
store r1, countdec r2store r2, count
Time Control Flow Command r1 r2 count
1 Producer load r1, count 5 - 5
2 Producer inc r1 6 - 5
3 Consumer load r2 count 6 5 53 Consumer load r2, count 6 5 5
4 Consumer dec r2 6 4 5
5 Producer store r1 count 6 4 65 Producer store r1, count 6 4 6
611
Is this Solution Correct?
Producer: count++ Consumer: count--
load r1, countinc r1
load r2, countdec r2inc r1
store r1, countdec r2store r2, count
Time Control Flow Command r1 r2 count
1 Producer load r1, count 5 - 5
2 Producer inc r1 6 - 5
3 Consumer load r2 count 6 5 53 Consumer load r2, count 6 5 5
4 Consumer dec r2 6 4 5
5 Producer store r1 count 6 4 65 Producer store r1, count 6 4 6
6 Consumer store r2, count 6 4 412
Critical Sections
Solution: Critical Sections
Control Flow 1: Producer Control Flow 2: Consumer
while(true) {Item item = produce();while(counter = SIZE) { }
while(true) {while(counter = 0) { }Item item = buffer[out];
buffer[in] = item;in = (in + 1) % SIZE;beginCriticalSection();
counter++;
out = (out + 1) % SIZE;beginCriticalSection();
counter--;endCriticalSection();counter++;
endCriticalSection();}
endCriticalSection();consume(item);
}
Essential Property:Critical Section is passed mutually exclusive!Critical Section is passed mutually exclusive!
14
Requirements to a Critical Section Solutionq
Mutual exclusion – Only one process can execute in the critical section at a time
Progress – Only threads that wish to enter the critical section participate in the decision on whichcritical section participate in the decision on which one can enter
Bounded waiting – Bound on the number of ti th t th th d ll d t ttimes that other threads are allowed to enter before the critical section is granted to a
ti th drequesting thread15
Dekker’s Algorithm
16
Model
Question: which basic operations are sufficient to realize the ti d i t f iti l ti ?mentioned requirements for critical sections?
Answer: two atomic“ operations are sufficient Answer: two „atomic operations are sufficient reading the value of a variable writing a value into a variable g
(We can also limit the previous to reading/writing of registers)
Atomic operation means: this is one single non-interruptablehi i t ti A t t it h h b fmachine instruction. A context switch may happen before or
after the instruction is executed but not in between.
17
We try to solve the problem for two processesy p p
/* some initialization of common variables first *//* common variable means that it is used by both processes */y p/* for an int variable i used by both processes we write */common int i;
/* the t o considered processes follo then e rite *//* the two considered processes follow then; we write: *//* process 1 */ /* process 2 */P1 :: /* code before */ P2 :: /* code before */
/* critical section */ /* critical section *//* code after */ /* code after */
/* we use the function name `yield()´ whenever a process finds thatit is blocked and thus can not enter the critical section Afterit is blocked and thus can not enter the critical section. Aftercalling yield() a process just tries a little later to enteragain. */
18
A first try...ycommon int mark = 1; /* initialization */
P1 :: while (mark != 1) yield(); P2 :: while (mark !=2) yield();/* critical section */ /* critical section */mark = 2; mark = 1;
19
A second try...ycommon int entry = open; /* initialization */
/* open = 0 and closed = 1 */p
P1 :: while(entry==closed) yield(); P2 :: while(entry==closed) yield();entry = closed; entry = closed;/* critical section */ /* critical section *//* critical section */ /* critical section */entry = open; entry = open;
20
A third try...ycommon int p1 = outside; /* initialization */common int p2 = outside; /* outside = 0 and inside = 1 */p
P1 :: p1 = inside; P2 :: p2=inside;while(p2==inside) yield(); while(p1==inside) yield();/* critical section */ /* critical section *//* critical section */ /* critical section */p1 = outside; p1 = outside;
21
A fourth try...ycommon int p1 = outside; /* initialization */common int p2 = outside; /* inside = 1 and outside = 0 */p
P1 :: do { P2 :: do {p1=inside; p2=inside;if(p2 inside) if(p1 inside)if(p2==inside) if(p1=inside)
p1=outside; p2=outside;while(p2==inside) yield(); while(p1==inside) yield();
} while(p1==outside) } while(p2==outside)p p/* critical section */ /* critical section */p1 = outside; p2 = outside;
22
A fifth try... (Dekker‘s Solution)y ( )common int p1 = outside; /* initialization */common int p2 = outside; /* inside = 1 and outside = 0 */pcommon in mark = 1;
P1 :: p1 = inside; P2 :: p2 = inside;if(p2 inside) { if(p1 inside) {if(p2==inside) { if(p1=inside) {if(mark==2) { if(mark==1) {
p1=outside; p2=outside;while(mark==2) yield(); while(mark==1) yield();y yp1=inside; } p2=inside; }
while(p2==inside) yield(); } while(p1==inside) yield(); }/* critical section */ /* critical section */mark = 2; mark = 1;mark = 2; mark = 1;p1 = outside; p2 = outside;
Correctness (proof idea):(p )• This solution is (more or less) an extension of Solution 4 and Solution 4 is an
extension of Solution 3.• Solution 3 assures mutual exclusion but may lead to a deadlock.
23
• Solution 4 removes the deadlock problem but introduces a potential lifelock.• Solution 5 then also removes the lifelock problem.
Peterson’s Solution
(1) Store which Thread is Allowed to Enter( )
Thread1 with id1 Thread2 with id2
enterCS() {while(turn != id1)
enterCS() {while(turn != id2)while(turn ! id1)
yield();}
while(turn ! id2)yield();
}
exitCS() {turn = id2;
exitCS() {turn = id1;turn = id2;
}turn = id1;
}
Again: Requires strict alternation of threads in the execution of their critical sections Progress requirementexecution of their critical sections Progress requirement not met!
25
(2) Store which Thread is Willing to Enter( ) g
Thread1 Thread2
enterCS() { enterCS() {flag1 = true;while(flag2)
flag2 = true;while(flag1)
yield();}
yield();}
exitCS() { exitCS() {flag1= false;
}flag2= false;
}} }
26
(2) Store which Thread is Willing to Enter( ) g
Correctness?
Thread1 Thread2
flag1 = true
flag2 = true Thread1 and Thread2 loop forever
fl 2 i ld fl ldflag2 yield flag1 yield27
(3) Combine Solution 1 and 2( )
Thread1 with id1 Thread2 with id2
enterCS() {flag1 = true;
enterCS() {flag2 = true;
turn = id2;while(flag2 && turn == id2)
yield();
turn = id1;while(flag1 && turn == id1)
yield();yield();}
yield();}
exitCS() {flag1= false;
}
exitCS() {flag2= false;
}} }
This solution is after Peterson and is called the Peterson’s Solution or P t ’ Al ithPeterson’s Algorithm.
28
Correctness
Thread1 with id1 Thread2 with id2
enterCS() {flag1 = true;
enterCS() {flag2 = true;
turn = id2;while(flag2 && turn == id2)
yield();
turn = id1;while(flag1 && turn == id1)
yield();yield();}
yield();}
Mutual Exclusion – Assume for the sake of contradiction that both processes exitCS() {
flag1= false;}
exitCS() {flag2= false;
}
pare in the critical section Case 1: Thread1 entered due to flag2==false. For Thread2 follows:• On entry of Thread 1, Thread 2 was executing before the line “flag2 = true”} }
This solution is after Peterson and is called the Peterson’s Solution or P t ’ Al ith
• When Thread 2 enters, follows for flag1 and turn:
Peterson’s Algorithm.
29
• Thus, the while condition for Thread 2 is still met, and Thread could not enter. A contradiction.
Correctness
Thread1 with id1 Thread2 with id2
enterCS() {flag1 = true;
enterCS() {flag2 = true;
turn = id2;while(flag2 && turn == id2)
yield();
turn = id1;while(flag1 && turn == id1)
yield();yield();}
yield();}
Mutual Exclusion – Assume for the sake of contradiction that both processes exitCS() {
flag1= false;}
exitCS() {flag2= false;
}
pare in the critical section Case 2: Thread1 entered due to turn==id1. For Thread2 follows:• Thread2 sets “turn = id1” after Thread1 has set “turn=id2”} }
This solution is after Peterson and is called the Peterson’s Solution or P t ’ Al ith
• Thus, when Thread2 enters, for flag1 must hold:
Peterson’s Algorithm.
30
• Thus, Thread2 sets “turn = id1” before Thread1 passes the line “flag1=true”• Thus, Thread1 sets “turn =id2” after Thread2 has set “turn=id1”. A
contradiction.
Correctness
Thread1 with id1 Thread2 with id2
enterCS() {flag1 = true;
enterCS() {flag2 = true;
turn = id2;while(flag2 && turn == id2)
yield();
turn = id1;while(flag1 && turn == id1)
yield();yield();}
yield();}
exitCS() {flag1= false;
}
exitCS() {flag2= false;
}} }Progress – Let Thread2 already having passed the critical section; i.e. it is currently now willing to enter the critical section. For flag2 eventually holds:
31Thread1 can immediately enter the critical section when passing the while loop.
Correctness
Thread1 with id1 Thread2 with id2
enterCS() {flag1 = true;
enterCS() {flag2 = true;
turn = id2;while(flag2 && turn == id2)
yield();
turn = id1;while(flag1 && turn == id1)
yield();yield();}
yield();}
exitCS() {flag1= false;
}
exitCS() {flag2= false;
}Bounded Waiting – When Thread1 is in the while loop flag1 satisfies:} }Bounded Waiting When Thread1 is in the while loop flag1 satisfies:
Thus, then Thread2 exists the critical section and when it wants to enter again:
32
us, t e ead e sts t e c t ca sect o a d e t a ts to e te aga
Peterson’s and Decker’s Solution discussed
Both require three variables to realize a critical section The Dekker solution is a little more complex The Dekker solution is a little more complex However, for both we have to run over several lines of program
code to enter a critical sectionW h l t l ti We have seen only two process solutions
For Peterson‘s solution an N process solution exists; but it is quite complex and requires lots of tests before a process can
t iti l tienter a critical section In any case for the mentioned N process solution, the number N
of processes must be known
It would be nice if we had some hardware features at hand which help with critical sectionswhich help with critical sections
Idea: more complex atomic operations (compared to reading and writing a value)
33
Synchronization Hardware
Synchronization Hardwarey
Hardware instructions solving the critical section blproblem
Prevent interrupts during critical section Feasible in uniprocessor environment Not possible in multiprocessor systems, and moreover Communication expense in multiprocessor environment
i ith th b f CPU increases with the number of CPUs
At i i t ti Atomic instructions test_and_set swap
35
Test and Set
Test_and_set(var, data)old_data = var;var = data;return old_data;
Synchronization using test_and_set(i i i ll f l )(initially var=false)while(test_and_set(var,true))
i ld()yield();criticalSection();var = false;var = false;
36
Test and Set
(initially var=false)while(test_and_set(var,true))
yield();criticalSection();var = false;
Mutual Exclusion – is satisfied• When one process passes the while loop we have:
• Thus, all subsequent test_and_set calls from other processes always see:
• This keeps them form entering the critical section.
P i b i l ti fi d t illi t t th iti l
37
Progress – is obviously satisfied; every process not willing to enter the critical section has reset the variable var to false. Thus, entering depends only on processes willing to enter.
Swapp
swap(x,y)temp = x;x = y;y = temp;
Synchronization using swap (initially lock=false)key_i = true;do {
swap(lock, key_i);hil (k i t )while(key_i == true);
criticalSection();lock = false;lock = false;
38
Swapp
key_i = true;do {
swap(lock, key_i);hil (k i t )while(key_i == true);
criticalSection();lock = false;lock = false;
Mutual Exclusion – is satisfied• When one process passes the while loop we have:When one process passes the while loop we have:
• Thus, all subsequent swap calls from other processes always see:Thus, all subsequent swap calls from other processes always see:
• This keeps them form entering the critical section.
39
p gProgress – is obviously satisfied; every process not willing to enter the critical section has reset the variable lock to false. Thus, entering depends only on processes willing to enter.
Test and Set and Swapp
while(test_and_set(var,true))yield();
criticalSection();var = false;
key i = true;
a a se;
key_i = true;do {
swap(lock, key_i);while(key_i == true);criticalSection();lock = false;lock false;
Bounded Waiting – is not satisfied for both solutions. Obviously a process can reenter the critical section before a currently blocked process
40
can reenter the critical section before a currently blocked process.
Bounded-Waiting with test_and_setgcommon boolean waiting[N]; // all initialized to falsecommon boolean lock; // initialized to false
Algorithm for process pi;waiting[i] = true;k t
Mutual-exclusion:
C id t i ikey = true;while (waiting[i] && key)key = test_and_set(&lock);
waiting[i] = false;
Consider an entering process pi.For waiting[i] follows:
waiting[i] = false;
// critical section Thus, we can exit the while only if:
j = (i + 1) % n;while ((j != i) && !waiting[j])j = (j + 1) % n; Due to test and set this can happenj (j + 1) % n;
if (j == i)lock = false;
Due to test_and_set this can happen only for one process.
lock can be set to false again only
41
;elsewaiting[j] = false;
oc ca be set to a se aga o yonce the process already left the critical section.
Bounded-Waiting with test_and_setgcommon boolean waiting[N]; // all initialized to falsecommon boolean lock; // initialized to false
Algorithm for process pi;waiting[i] = true;k t
Progress:
O i l th iti lkey = true;while (waiting[i] && key)key = test_and_set(&lock);
waiting[i] = false;
Once process pi leaves the critical section it tries to find another process already waiting.
waiting[i] = false;
// critical sectionIf it finds one it sets this process’s waiting flag to false. The process can enter then immediately
j = (i + 1) % n;while ((j != i) && !waiting[j])j = (j + 1) % n;
enter then immediately.
If it finds no other waiting process, it sets lock to false Thus as soon aj (j + 1) % n;
if (j == i)lock = false;
sets lock to false. Thus, as soon a process is willing to enter it will find lock false and can enter immediately.
42
;elsewaiting[j] = false;
Bounded-Waiting with test_and_setgcommon boolean waiting[N]; // all initialized to falsecommon boolean lock; // initialized to false
Algorithm for process pi;waiting[i] = true;k t
Bounded-Waiting:
Once a process pi leaves the critical key = true;while (waiting[i] && key)key = test_and_set(&lock);
waiting[i] = false;
p psection, it scan the array of potential waiting processes in the following order:waiting[i] = false;
// critical section
j = (i + 1) % n;while ((j != i) && !waiting[j])j = (j + 1) % n;
However, it stops once it finds the first waiting process which can then enter.j (j + 1) % n;
if (j == i)lock = false;
Once this process leaves again, it continues the scan.
Thus each process waits at most:
43
;elsewaiting[j] = false;
Thus, each process waits at most:
Semaphores
Semaphoresp A synchronization tool to realize critical sections easier than directly
using hardware features like test-and-set or swapg p
A semaphore is a variable S with the following properties Integer variable S initialized to an integer value c Integer variable S initialized to an integer value c Accessed by atomic operations acquire() and release()
acquire(S) acquire(S) if S <= 0 then the process has to wait here else S = S – 1
release(S) release(S) S = S + 1 if one or more processes are waiting at semaphore S then
one process can continue nowp the process which continues now executes its outstanding S = S – 1 operation
acquire and release are also known as wait and signal or P and V
45
Semaphoresp
Modifications of S must be indivisiblyy No two threads can modify S simultaneously
Testing of S<=0 and possible modification must Testing of S<=0 and possible modification must be without interruption
Binary semaphores (aka. mutex locks) –Binary semaphores (aka. mutex locks) between 0 and 1Counting semaphores unrestricted domain Counting semaphores – unrestricted domain
46
Semaphoresp Example: Mutual exclusion
Semaphore S = 1; Semaphore S 1; ... // Thread’s code section ... acquire(S); criticalSection(); release(S);
Example: process p1 with state s1 and process p2 with statement s2. Statement s2 is only allowed to be executed after statement s1 Use a semaphore synch initialized to 0 Code of process p1
s1;l ( h) release(synch);
Code of process p2 acquire(synch); s2;
47
Semaphore Implementationp p How to implement ‘wait if S <= 0’? Solution 1 – empty while loopp y p
acquire(s) {while(s<=0) { } // finding s>0, leaving the while
// d lli b is--; // and calling s-- must be atomic}
release(s) {release(s) {s++;
}
Problems busy waiting! (also called spinlock) Single processor system: works only with preemptive scheduling
Advantage Advantage no context switch (Useful when spinlock is short)
Often used on a multiprocessor systemp y
48
Semaphore Implementationp p
Solution 2 – block and wakeupp acquire may switch a process into waiting
statestate PCB is placed in a waiting queue which is
associated with the semaphore (for instanceassociated with the semaphore (for instance, FIFO)
l h f iti t release may change a process from waiting to ready state
49
Semaphore Implementationp p
Solution 2 – block and wakeup
acquire(S) {S
release(S) {S++
Solution 2 block and wakeup
S--;if (S<0) {
add process
S++;if (S<=0) {
remove one processpto list;
block;}
pfrom list;
wakeup(process);}}
}}
}
50
Semaphores Discussed: Critical Sectionsp How to assure that acquire and release are executed atomically?
On a single processor system: disable interrupts when acquire and release operations are executing
On a multiprocessor system: interrupts must be enabled on all processes! This is expensive. Multiprocessor systems often use
i l ki i t dspinlocking instead.
That means that busy waiting is used. However, busy waitingThat means that busy waiting is used. However, busy waiting for a very short time period when executing acquire and release (which might should be no more than 10 instructions) instead of busy waiting at the whole critical section of programs (which y g p g (might be minutes, hours or even longer)
51
Semaphores Discussed: Deadlocks and Starvationp
Deadlock – every process in a set is waiting for an t f i th t tevent from a process in that set
Example with two binary semaphores S and Q
P PP0 P1
acquire(S) acquire(Q)
i (Q) i (S)acquire(Q) acquire(S)
… …
release(S) release(Q)
I d fi it bl ki it i d fi it l l
release(S) release(Q)
release(Q) release(S)
Indefinite blocking – a process waits indefinitely long within a semaphore (e.g. when list of processes blocked at a semaphore would be organized as LIFOblocked at a semaphore would be organized as LIFO queue)
52
Classic Synchronization Problems
Classical Synchronization Problemsy
The Producer-Consumer Problem The Readers-Writers Problem
Th Di i Phil h P bl The Dining-Philosophers Problem The Barrier-Synchronization Probleme a e Sy c o at o ob e
Semaphore solutions…
54
The Producer-Consumer Problem
0 1counter
0 SIZE-1
buffer
out in
// used to realize a critical section for// modifying a single buffer// y g gSemaphore mutex(1);
// used to block process on empty or full buffer// used to block process on empty or full bufferSemaphore empty(BUFFER_SIZE);Semaphore full(0);
55
The Producer-Consumer Problem
0 1counter
empty is initially BUFFER_SIZE;full is initially 0;
0 SIZE-1
buffer
// P d
// Consumer
while(true) {
out in
// Producerwhile(true) {
empty.acquire();
while(true) {
full.acquire();
mutex acquire();mutex.acquire();buffer[in] = produceItem();in = (in + 1) % BUFFER SIZE;
mutex.acquire();
consume(buffer[out]);
out = (out + 1) %_mutex.release();full.release();
}
out (out + 1) %
BUFFER_SIZE;
mutex.release();} ();
empty.release();
}56
The Readers-Writers Problem
Concurrent read and write operations on shared dataR di d dif d i l d Reading does not modify data simultaneous read operations are allowed
Writing modifies data requires exclusive access during Writing modifies data requires exclusive access during write
First readers-writers problem – no reader is kept waiting unless a writer has already obtained permission
Second readers-writers problem – once a writer is ready the writer performs its operation as soon as possible
Data item
Reader 1
Reader 2Writer 1
57
Data itemReader 3Writer 2
Example: First-Readers-Writers Problempint readerCount = 0;Semaphore mutex(1);p ( );Semaphore lock(1);
// Reader // Writermutex.acquire()readerCount++;if (readerCount == 1)
// Writer
lock.acquire();
lock.acquire();mutex.release(); <WRITE>
<READ>
mutex.acquire();d C t
lock.release();
readerCount--;if (readerCount == 0)
lock.release();mutex release();mutex.release();
58
The Dining-Philosophers Problemg p
From time to time philosopher tries to pick up the left and right chopstickright chopstick
Pick up only one chopstick at a time Chopstick is only available if not used by a neighbor Chopstick is only available if not used by a neighbor
59
The Dining-Philosophers Problemg p
Semaphore solution …
Semaphore chopStick[5];
// Philosopher iwhile(true) {
chopStick[i].acquire();chopStick[(i+1) % 5].acquire();<EATING><EATING>chopStick[i].release();chopStick[(i+1) % 5].release();p [( ) ] ();<THINKING>
}
60
The Dining-Philosophers Problemg p
This semaphore solution may produce a p y pdeadlock!
Remedies to the deadlock problem Allow at most four philosophers Pick both chop stick within a critical section Pick both chop stick within a critical section Introduce asymmetry (e.g. odd philosopher
picks up left chop stick and even philosopherpicks up left chop stick and even philosopher picks up right chop stick first)
61
The Barrier Problem
A set of processes p1,…,pn can continue only once all have d i l f h Thi i ll dpassed one single part of the program. This part is called a
barrier.
Parallel execution of all processes
barrierbarrier
O ll d th b iOnce all passed the barrier,parallel execution of all processes continues
62
A Possible Solution Assume N processes p1,…,pn. There is one additional process q which supervises the barrier There is one additional process q which supervises the barrier
synchronization. We use two semaphores s and t initialized to 0. To pass the barrier each process pi must execute the operations To pass the barrier, each process pi must execute the operations
t.release();s.acquire();
The code of the supervising processcnt=0while(true) {while(true) {
t.acquire()cnt++;if( t N) // ll i d t th b iif(cnt==N) // all processes arrived at the barrier
for i=0,..., N-1 : cnt--; s.release();
There are also (more complex) solutions which do not need the additional supervising process. 63
Monitors
Problems with Semaphoresp
Every acquire needs a release Requires careful programming Enables uncooperative programming
Error examples when realizing a critical section with semaphoressemaphores
mutex.release() mutex.acquire() Omit
<CS>
mutex.acquire()
<CS>
mutex.acquire()
mutex.acquire()
or
mutex.release()
Concurrent Access Deadlock Concurrent Access
or Deadlock65
Solution: Monitor
Encapsulated dataO i h d Operations on that data
Only one thread at a time has access to thetime has access to the monitor
Communication among threads are still missing
66
Solution: Condition Variables
wait – thread exits it d imonitor and is
suspended
signal – resume exactly one thread waiting at xone thread waiting at x
Signal Variants: FCFS
• condition variabe x;
• x wait(); Signal Variants: FCFS, Priorities
67
x.wait();
• x.signal();
Solution: Condition Variables
Difference between signal and a semaphore release ti Si l h ff t h th d ioperation: Signal has no effect when no thread is
waiting
Signaling semantics when P signals and Q was waitingwaiting
1. Signal and wait – P waits for Q leaving the monitor2. Signal and continue – Q waits for P leaving the monitorg Q g
Both variants are reasonable1. For signal and wait: if P continues, then once Q enters the
h d l d b h l h ldmonitor, the condition signaled by P might no longer hold2. For signal and continue: P is already in the monitor, so it is
reasonable that P continues.reasonable that P continues.
68
Dining Philosophers using Monitors
monitor DiningPhilosophers { condition[] self = new condition[5];condition[] self new condition[5];
void pickUp(int i) { state[i] = HUNGRY;state[i] = HUNGRY;possibly_start_to_eat(i);if (state[i] != EATING)
lf[i] it()self[i].wait();}
void possibly_start_to_eat(int i) { if ( (state[(i + 4) % 5] != EATING) &&
(state[i] == HUNGRY) &&(state[(i + 1) % 5] != EATING) ) {
state[i] = EATING;self[i].signal();self[i].signal();
}} 69
Dining Philosophers using Monitors
void putDown(int i) { state[i] = THINKING;// test left and right neighborspossibly_start_to_eat ((i + 4) % 5);_ _ _possibly_start_to_eat ((i + 1) % 5);
}
}
Each philosopher uses a common used monitor dp andEach philosopher uses a common used monitor dp and executes the following monitor calls
dp pickUp();dp.pickUp();
<eat>
dp.putDown();70
Implementing a Semaphore using Monitorsp g p g
monitor sem {int count;int count;Condition blocked = new Condition();
Semaphore(int i) {Semaphore(int i) {count = i;
}
void acquire() {count--;
void release() {count++;if(count <= 0) {if(count < 0) {
blocked.wait();}
if(count <= 0) {blocked.signal();
}}
}
}71
Implementing a Monitor using Semaphoresp g g p
Replace each function and condition variable access with i h i i dappropriate synchronization code
A h i i bi h Access to the monitor requires a binary semaphore mutex Signaling requires a waiting queue implemented by a
counting semaphore t and a counter t tcounting semaphore next and a counter next_count Each condition variable x requires a counting semaphore x sem and a counter x countx_sem and a counter x_count
Here we implement the signal and wait variant i e the Here we implement the signal and wait variant, i.e., the signaling process gets blocked and on of the signaled processes can resume operation in the monitor.processes can resume operation in the monitor.
72
Replacing Functionsp g
mutex.acquire();
f(…) {<BODY>
if (next count > 0)<BODY>
}
if (next_count > 0)
next.release();}
else
mutex release();mutex.release();
73
Replacing of x.wait() in a Function Bodyp g () y
x_count++;
if(next count > 0)
it()
( _ )
next.release();
x.wait() else
mutex.release();
x_sem.aquire();
tx_count--;
74
Replacing of x.signal() in a Function Bodyp g g () y
if (x_count > 0) {
i l()
next_count++;
x sem release();x.signal(); x_sem.release();
next.acquire();
next_count--;
}}
75
Synchronization Examples
Example: The Monitor Concept with Javap p
Every object owns a lock Usage of a lock
public synchronized <ret> f(<val>) {...
}
The concept of conditional wait; inside a p ;synchronized method you can call wait(); notify(); notifyAll();
77
Synchronization Examples: Solarisy p Adaptive mutex
Protect a critical data item on a multiprocessor system Protect a critical data item on a multiprocessor system Lock held by a running thread spinlock Lock held by a sleeping process thread blocks Reasonable for short instruction sequencesq
Reader-writer lock Allows several read accesses Write access is assured to be mutually exclusive (and without a read)
Turnstile – Solaris waiting queue implementationTurnstile Solaris waiting queue implementation Critical data item has no own thread waiting queue Each thread owns a waiting queue
On access of free item the queue is assigned to the item When releasing the item the thread gets a new turnstile
Advantage: resource efficient Priority inheritance in order to prevent priority inversion
78
Synchronization Examples: Windows XPy p
Kernel access on global resourceSi l Single processor Masking of relevant interrupts
Multiprocessoru p o esso Spinlocking for short code segments Spinlocking thread is not preempted
Synchronization outside the kernel Dispatcher objects: mutex, semaphore, events, timers Dispatcher objects: mutex, semaphore, events, timers Changes between two states
Signaled – thread does not blockN i l d th d i bl k d d l d i t Non signaled – thread is blocked and placed into a queue
Dispatcher object type determines How many threads get ready when changing to signaledy g y g g g
79
Synchronization Example: Linuxy p
Preemption kernel since version 2.6p
H ldi l k f h t ti Holding a lock for a short time Single processor – enable/disable kernel g p
preemption SMP – spinlocks SMP spinlocks
Holding a lock for a longer periodS h Semaphores
80
Synchronization Example: Pthreadsy p
mutex locks, condition variables, read-write locks
Some system provide also semaphores not part of Pthread standard not part of Pthread standard Belongs to POSIX SEM extension
Other extensions of Pthread APIi l k spinlock
not all extensiosn are considered portable from one implementaot to anotherimplementaot to another
81
Atomic Transactions
Atomic Transactions A topic related to data base systems. However, operating
systems are also concerned about managing data; thus, theysystems are also concerned about managing data; thus, they could benefit of techniques known for database systems
Transaction sequence of instructions that access and update Transaction – sequence of instructions that access and update data items as a single logical function
E l F d t f d bit d dit t b th Example: Funds transfer; debit and credit must occur both or not at all
Instructions Data access: read, write Termination: abort, commit Termination: abort, commit
Abort and system failure requires rollback: restore data as it was before the whole transaction startedwas before the whole transaction started
83
Log-based Recoveryg y
Write ahead lock Every write, commit and abort is logged to
stable storage Write entry includes old and new value
Enables redo in case of system failureE bl d i f b t Enables undo in case of abort
Failure during redo or undo? idempotency requiredidempotency required
84
Recovery after System Failurey y
Redo for all logged transactions completed with a commitwith a commit
Undo for all logged transactions which do not contain a commitcontain a commit
Efficiency? Old transactions may be outdatedoutdated
Check points Check points Periodically write volatile data to stable storage
Mark this event by a check point Mark this event by a check point Recovery of only these transaction which where not
completed or aborted before the last checkpointp p
85
Concurrent Atomic Transactions
Concurrent execution of transactions must be equivalent to their serial executionDenoted as serial schedule Denoted as serial schedule
Example: T1 T2
read(A)
write(A)
read(B)
write(B)
read(A)read(A)
write(A)
read(B)( )
write(B)86
Concurrent Atomic Transactions
In general, operations of different schedules g , pmay overlap non serial scheduleExample: T1 T2 Example: T1 T2
read(A)
write(A)write(A)
read(A)
write(A)
read(B)
write(B)
e d(B)
I thi h d l t?
read(B)
write(B)
Is this schedule correct?87
Concurrent Atomic Transactions
Conflict serializable – schedule can be transformed to a serial one by swapping non conflicting operationsnon conflicting operations
Conflicting operations – consecutive i i h d ioperations accessing the same data item
with one operation being a writep g Example: T1 T2
…
write(A)
read(A)
…
88
Concurrent Atomic Transactions
Correctness of the example schedulep
T1 T2T1 T2
read(A)
write(A)write(A)
read(A)
write(A)
read(B)
write(B)
e d(B)read(B)
write(B)
89
Concurrent Atomic Transactions
Correctness of the example schedulep
T1 T2T1 T2
read(A)
write(A)write(A)
read(A)
write(A)
read(B)
write(B)
e d(B)read(B)
write(B)
90
Concurrent Atomic Transactions
Correctness of the example schedulep
T1 T2T1 T2
read(A)
write(A)write(A)
read(A)
read(B)
write(A)
write(B)
e d(B)read(B)
write(B)
91
Concurrent Atomic Transactions
Correctness of the example schedulep
T1 T2T1 T2
read(A)
write(A)write(A)
read(B)
read(A)
write(A)
write(B)
e d(B)read(B)
write(B)
92
Concurrent Atomic Transactions
Correctness of the example schedulep
T1 T2T1 T2
read(A)
write(A)write(A)
read(B)
read(A)
write(B)
write(A)
e d(B)read(B)
write(B)
93
Concurrent Atomic Transactions
Correctness of the example schedulep
T1 T2T1 T2
read(A)
write(A)write(A)
read(B)
write(B)
read(A)
write(A)
e d(B)read(B)
write(B)
94
Two-Phase Locking Protocolg
Each data item has a lock which has to be granted before accessbefore access
Possible modes Shared – multiple transactions may read Shared – multiple transactions may read Exclusive – one transaction may read or write
Two-Phase Locking ensures serializability Growing phase – transaction may only acquire further g p y y q
locks Shrinking phase – transaction may only release locks
PropertiesConflict serializability Conflict serializability
May result in a deadlock95
Timestamp-based Protocolp
Every transaction gets a timestamp on y g pstartup (system clock, logical clock)
Every data item Q has two timestamp values W(Q) – largest timestamp of the last successful W(Q) largest timestamp of the last successful
write on QR(Q) largest timestamp of the last successful R(Q) – largest timestamp of the last successful read on Q
96
Timestamp-based Protocolp
Timestamp ordering protocol Ti issues a read(Q)
TS(Ti) < W(Q) rollback TiOtherwise execute read(Q)
Ti issues a write(Q)TS(Ti) < R(Q) rollback Ti
TS(Ti) < W(Q) rollback TiOtherwise execute write(Q)Otherwise execute write(Q)
P ti Properties Conflict serializable Free from deadlocks
97
Summary and References
Summaryy The problem arises from multiple processes accessing a shared data item General solution: mutual exclusion
User coded solutions (Dekker’s and Peterson’s Algorithms): problem busy-waiting Hardware Solutions: swap, test_and_set
S h ll h i i i h b i i Semaphores: allow synchronization without busy-waiting However, exception spinlocking in case of short handling times in multiprocessor
system
Synchronization by directly using Semaphores can be error prone Possible solution: monitor concept and signaling
Synchronization problems (bounded-buffer, readers-writers, dining philosophers) represent a wide class of synchronization problems used to evaluate new synchronization concepts
Operating system deals with data access; interesting to consider the database concept of transactions as a part of the OS
99
References
Silberschatz, Galvin, Gagne, „Operating , , g , „ p gSystem Concepts“, Seventh Edition, Wiley, 20052005 Chapter 6 „Process Synchronization“
100