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






Time Control Flow Command r1 r2 count

1

2

33

4

55

66







1 Producer load r1, count 5 - 5

2

33

4

55

67








2 Producer inc r1 6 - 5

33

4

55

68









3 Consumer load r2 count 6 5 53 Consumer load r2, count 6 5 5

4

55

69










4 Consumer dec r2 6 4 5

55

610











5 Producer store r1 count 6 4 65 Producer store r1, count 6 4 6

611











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


enterCS() {flag1 = true;


turn = id2;while(flag2 && turn == id2)

yield();


yield();yield();}

yield();}

exitCS() {flag1= false;

}


}} }

This solution is after Peterson and is called the Peterson’s Solution or P t ’ Al ithPeterson’s Algorithm.

28

Correctness





yield();


yield();yield();}

yield();}

Mutual Exclusion – Assume for the sake of contradiction that both processes exitCS() {

flag1= 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





yield();


yield();yield();}

yield();}

Mutual Exclusion – Assume for the sake of contradiction that both processes exitCS() {

flag1= 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





yield();


yield();yield();}

yield();}


}


}} }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





yield();


yield();yield();}

yield();}


}


}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.



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;


sets lock to false. Thus, as soon a process is willing to enter it will find lock false and can enter immediately.

42




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;


Once this process leaves again, it continues the scan.

Thus each process waits at most:

43


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


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


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


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


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


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



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



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



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



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



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

process synchronization - uni koblenz-landauunikorn/lehre/... · code to enter a critical section...

Documents