Chapter 6 Process Synchronization Module 6 Process Synchronization

Chapter 6: Process Synchronization

Module 6: Process Synchronization n n n n Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Atomic Transactions Operating System Concepts 6. 2 Silberschatz, Galvin and Gagne © 2005

Key Terms Operating System Concepts 6. 3 Silberschatz, Galvin and Gagne © 2005

Background n Concurrent access to shared data may result in data inconsistency n Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes n Suppose that we wanted to provide a solution to the consumer-producer problem that fills all the buffers. We can do so by having an integer count that 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 and is decremented by the consumer after it consumes a buffer. Operating System Concepts 6. 4 Silberschatz, Galvin and Gagne © 2005

Race Condition l An unanticipated execution ordering of concurrent flows that results in undesired behavior is called a race condition—a software defect and frequent source of vulnerabilities. l Race conditions result from runtime environments, including operating systems, that must control access to shared resources, especially through process scheduling. Operating System Concepts 6. 5 Silberschatz, Galvin and Gagne © 2005

Race Condition Example n count++ could be implemented as register 1 = count register 1 = register 1 + 1 count = register 1 n count-- could be implemented as register 2 = count register 2 = register 2 - 1 count = register 2 n Consider this execution interleaving with “count = 5” initially: S 0: producer execute register 1 = count {register 1 = 5} S 1: producer execute register 1 = register 1 + 1 {register 1 = 6} S 2: consumer execute register 2 = count {register 2 = 5} S 3: consumer execute register 2 = register 2 - 1 {register 2 = 4} S 4: producer execute count = register 1 {count = 6 } S 5: consumer execute count = register 2 {count = 4} Operating System Concepts 6. 6 Silberschatz, Galvin and Gagne © 2005

Critical Section n Informally, a critical section is a code segment that accesses shared variables and has to be executed as an atomic action. n The critical section problem refers to the problem of how to ensure that at most one process is executing its critical section at a given time. Operating System Concepts 6. 7 Silberschatz, Galvin and Gagne © 2005

Example n Suppose we have to implement a function to handle withdrawals from a bank account: n Now suppose that you and your significant other share a bank account with a balance of $1000. n Then you each go to separate ATM machines and simultaneously withdraw $100 from the account. Operating System Concepts 6. 8 Silberschatz, Galvin and Gagne © 2005

n We’ll represent the situation by creating a separate thread for each person to do the withdrawals n These threads run in the same bank process: n What’s the problem with this implementation? n Think about potential schedules of these two threads Operating System Concepts 6. 9 Silberschatz, Galvin and Gagne © 2005

n The problem is that the execution of the two threads can be interleaved: n What is the balance of the account now? n This is known as a race condition n Each thread is “racing” to put_balance() before the other Operating System Concepts 6. 10 Silberschatz, Galvin and Gagne © 2005

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 l Only one process can be in the critical section at a time -- otherwise what critical section? . 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 l No process is forced to wait for an available resource -- otherwise very wasteful. 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 Operating System Concepts 6. 11 Silberschatz, Galvin and Gagne © 2005

Mutual Exclusion n One way to ensure who wins the race is to only let one thread “compete”; this is called mutual exclusion n Code that uses mutual exclusion to synchronize its execution is called a critical section l Only one thread at a time can execute in the critical section l All other threads are forced to wait on entry l When a thread leaves a critical section, another can enter Operating System Concepts 6. 12 Silberschatz, Galvin and Gagne © 2005

Lock n To implement critical section, we need to use acquire lock and release lock n Lock is an object in memory providing two operation l Acquire() : before entering critical section => getting the lock l Release() section : after finishing operation in critical => return the lock n While one thread grab the lock, the other thread have to spin, while waiting Operating System Concepts 6. 13 Silberschatz, Galvin and Gagne © 2005

n Between acquire() and release(), the thread holds critical section n What happened if two operation are not paired ? Operating System Concepts 6. 14 Silberschatz, Galvin and Gagne © 2005

How the lock works n Blue thread grab the lock, while the other two threads keep spinning, waiting for the lock n When they do spinning, they enter busy waiting state Operating System Concepts 6. 15 Silberschatz, Galvin and Gagne © 2005

n The other two threads are put in a queue, one after the other n This to determine who will get the lock after the blue thread Operating System Concepts 6. 16 Silberschatz, Galvin and Gagne © 2005

n The other twos, while waiting in the queue, keeps on spinning n Once a while, they both keep on doing checking , whether blue thread has release the lock n The spinning and the test consume CPU operation Operating System Concepts 6. 17 Silberschatz, Galvin and Gagne © 2005

In the program Operating System Concepts 6. 18 Silberschatz, Galvin and Gagne © 2005

Synchronization Hardware n The implementation of acquire/release must be atomic n An atomic operation is one which executes as though it could not be interrupted l Code that executes “all or nothing” or uninterruptable n How do we make them atomic? l Need help from hardware n Hardware solution : Atomic instructions l Disable/enable interrupts (prevents context switches) l Operating System Concepts 6. 19 Silberschatz, Galvin and Gagne © 2005

Atomic Instruction n What about using a binary “lock” variable in memory and having processes check it and set it before entry to critical regions? n Many computers have some limited hardware support for setting locks l “Atomic” Test and Set Lock instruction l “Atomic” compare and swap operation Operating System Concepts 6. 20 Silberschatz, Galvin and Gagne © 2005

Test-and-set n Lock is stored in a memory location that contains 0 or 1 n Test-and-set (attempt to acquire) writes a 1 and returns the value in memory n If the value is 0, the process gets the lock; if the value is 1 another process has the lock. n To release, just clear (set to 0) the memory location. Synchron. CSE 471 Operating System Concepts 6. 21 21 Silberschatz, Galvin and Gagne © 2005

Test. And. Set int Test. And. Set(int *old_ptr, int new) { // fetch old value at old_ptr int old = *old_ptr; // store ’new’ into old_ptr *old_ptr = new; // return the old value return old; } Operating System Concepts 6. 22 Silberschatz, Galvin and Gagne © 2005

typedef struct __lock_t { int flag; } lock_t; void init (lock_t *lock) { // 0 indicates that lock is available, 1 that it is held lock->flag = 0; } void lock (lock_t *lock) { while (Test. And. Set(&lock->flag, 1) == 1) // spin-wait (do nothing) ; } void unlock (lock_t *lock) { lock->flag = 0; } Operating System Concepts 6. 23 Silberschatz, Galvin and Gagne © 2005

Problem with Lock n The problem with this implementation is busy- waiting. n Busy waiting wastes CPU cycles n Longer the CS, the longer the spin n Greater the chance for lock holder to be interrupted n If a thread is spinning on a lock, then the thread holding the lock cannot make progress Operating System Concepts 6. 24 Silberschatz, Galvin and Gagne © 2005

n How did the lock holder give up the CPU in the first place? l Lock holder calls yield or sleep l Involuntary context switch l Only want to use spinlocks as primitives to build higherlevel synchronization constructs Operating System Concepts 6. 25 Silberschatz, Galvin and Gagne © 2005

Disabling Interrupt n Uniprocessors – could disable interrupts Currently running code would execute without preemption n Generally too inefficient on multiprocessor systems l Operating systems using this not broadly scalable l n Operating System Concepts 6. 26 Silberschatz, Galvin and Gagne © 2005

n Disabling interrupts blocks notification of external events that could trigger a context switch (e. g. , timer) Operating System Concepts 6. 27 Silberschatz, Galvin and Gagne © 2005

Solution Operating System Concepts 6. 28 Silberschatz, Galvin and Gagne © 2005

Implementing Lock by Disabling Interrupt Operating System Concepts 6. 29 Silberschatz, Galvin and Gagne © 2005

Classical Problems of Synchronization n Bounded-Buffer Problem n Readers and Writers Problem n Dining-Philosophers Problem Operating System Concepts 6. 30 Silberschatz, Galvin and Gagne © 2005

The Producer - Consumer Problem • Producer pushes items into the buffer. • Consumer pulls items from the buffer. • Producer needs to wait when buffer is full. • Consumer needs to wait when the buffer is empty. Operating System Concepts 6. 31 Silberschatz, Galvin and Gagne © 2005

Operating System Concepts 6. 32 Silberschatz, Galvin and Gagne © 2005

Potential Problem n Detecting when the buffer full or empty n The buffer size has to be the same for both producer and customer Operating System Concepts 6. 33 Silberschatz, Galvin and Gagne © 2005

Readers-Writers Problem n A data set is shared among a number of concurrent processes l Readers – only read the data set; they do not perform any updates l Writers – can both read and write. n Allow multiple readers to read at the same time. Only one single writer can access the shared data at the same time Operating System Concepts 6. 34 Silberschatz, Galvin and Gagne © 2005

n Multiple reader or one writer can enter the database Operating System Concepts 6. 35 Silberschatz, Galvin and Gagne © 2005

Potential Problem n How to allow multiple reader or single writer for the shared data Operating System Concepts 6. 36 Silberschatz, Galvin and Gagne © 2005

Dining-Philosophers Problem Operating System Concepts 6. 37 Silberschatz, Galvin and Gagne © 2005

n N philosopher sitting in a circular table n One chopstick is placed between each philosopher n The philosopher has two state : eating and thinking n To enter eating state, a philosopher must grab two chopstick (both left and right chopstick ) one by one n After satisfy, a philosopher must put down two chopstick (both left and right chopstick ) one by one n The philosopher enter thinking state Operating System Concepts 6. 38 Silberschatz, Galvin and Gagne © 2005

Potential Problem n Every philosopher has access to rice bowl => no starvation n Two philosopher sit next to each other may grab the same chopstick => cause deadlock Operating System Concepts 6. 39 Silberschatz, Galvin and Gagne © 2005

Real Example of Synchronization Problem n Producer-consumer l Audio-Video player: network and display threads; shared buffer n Reader-writer l Banking 4 read Operating System Concepts system: account balances versus update 6. 40 Silberschatz, Galvin and Gagne © 2005

n Dining Philosophers l Cooperating processes that need to share limited resources l Set of processes that need to lock multiple resources 4 Disk l Travel and tape (backup) reservation: 4 hotel, Operating System Concepts airline, car rental databases 6. 41 Silberschatz, Galvin and Gagne © 2005

Semaphore n Semaphore is used to detect free resources, so process don’t n n need to do busy waiting Synchronization tool that does not require busy waiting l Busy waiting means the repeating while loop , to check mutex condition => cause process in the run queue l It can not wake up to see the condition false Semaphore S – integer variable Two standard operations modify S: wait() and signal() l Originally called P() and V() Less complicated Note : Semaphore only able to detect if there is free resource. There is no mechanism to choose which resource for which process Operating System Concepts 6. 42 Silberschatz, Galvin and Gagne © 2005

Operating System Concepts 6. 43 Silberschatz, Galvin and Gagne © 2005

Semaphore as General Synchronization Tool n Counting semaphore – integer value can range over an unrestricted domain n Binary semaphore – integer value can range only between 0 and 1; can be simpler to implement l Also known as mutex locks n Can implement a counting semaphore S as a binary semaphore n Provides mutual exclusion l Semaphore S; l wait (S); // initialized to 1 Critical Section signal (S); Operating System Concepts 6. 44 Silberschatz, Galvin and Gagne © 2005

Counting Semaphore n Can only be accessed via two indivisible (atomic) operations l wait (S) { while S <= 0 /* as long as S less than 0, don’t wait anymore ; // no-op //we wait, while other process enter critical zone S-} l signal (S) { //after other finishing critical zone, we able to use resource S++; } Operating System Concepts 6. 45 Silberschatz, Galvin and Gagne © 2005

Semaphore Implementation n Must guarantee that no two processes can execute wait () and signal () on the same semaphore at the same time n Thus, implementation becomes the critical section problem where the wait and signal code are placed in the crtical section. l Could now have busy waiting in critical section implementation 4 But implementation code is short 4 Little busy waiting if critical section rarely occupied n Note that applications may spend lots of time in critical sections and therefore this is not a good solution. Operating System Concepts 6. 46 Silberschatz, Galvin and Gagne © 2005

Semaphore Implementation with no Busy waiting n With each semaphore there is an associated waiting queue. Each entry in a waiting queue has two data items: l value (of type integer) l pointer to next record in the list n Two operations: l block – place the process invoking the operation on the appropriate waiting queue. => implementation of wait() l wakeup – remove one of processes in the waiting queue and place it in the ready queue => implementation of signal() n http: //williamstallings. com/OS-Animation/Queensland/SEMA. SWF Operating System Concepts 6. 47 Silberschatz, Galvin and Gagne © 2005

Semaphore Implementation with no Busy waiting (Cont. ) n Implementation of wait: wait (S){ value--; if (value < 0) { //add this process to waiting queue block(); } } n Implementation of signal: Signal (S){ value++; if (value <= 0) { remove a process P from the waiting queue wakeup(P); } } Operating System Concepts 6. 48 Silberschatz, Galvin and Gagne © 2005

Deadlock and Starvation n Deadlock – two or more processes are waiting indefinitely for an event that can be caused by only one of the waiting processes n Let S and Q be two semaphores initialized to 1 P 0 P 1 wait (S); wait (Q); . . . signal (S); signal (Q); wait (S); . . . signal (Q); signal (S); n Starvation – indefinite blocking. A process may never be removed from the semaphore queue in which it is suspended. Operating System Concepts 6. 49 Silberschatz, Galvin and Gagne © 2005

Solving Bounded-Buffer Problem with semaphore n The buffer size must remain consistent for both producer and customer n While writing data (either producing or consuming), you must make sure that no thread change the data n When finish operation, tell the other (producer/customer) the number of empty slot / number of full slot n Shared data : buffer size, with N capacity n Semaphore : l Binary Semaphore mutex initialized to the value 1 l Counting Semaphore full initialized to the value 0 l Counting Semaphore empty initialized to the value N. n http: //williamstallings. com/OS-Animation/Queensland/BB. SWF Operating System Concepts 6. 50 Silberschatz, Galvin and Gagne © 2005

Bounded Buffer Problem (Cont. ) n The structure of the producer process do { // produce an item wait (empty); wait (mutex); // add the item to the buffer signal (mutex); signal (full); } while (true); Operating System Concepts 6. 51 Silberschatz, Galvin and Gagne © 2005

Bounded Buffer Problem (Cont. ) n The structure of the consumer process do { wait (full); wait (mutex); //enter mutex // remove an item from buffer signal (mutex); signal (empty); // consume the removed item } while (true); Operating System Concepts 6. 52 Silberschatz, Galvin and Gagne © 2005

Solving Readers-Writers Problem n The number of writer and readers must remain the same n If there is only one reader, deny any writer n If the readers finish operation, allow writer to enter n Shared Data : l Number of readers l Number of writers n Semaphore l Semaphore mutex initialized to 1. l Semaphore wrt initialized to 1. l Integer readcount initialized to 0. Operating System Concepts 6. 53 Silberschatz, Galvin and Gagne © 2005

Readers-Writers Problem (Cont. ) n The structure of a writer process do { wait (wrt) ; // writing is performed signal (wrt) ; } while (true) Operating System Concepts 6. 54 Silberschatz, Galvin and Gagne © 2005

Readers-Writers Problem (Cont. ) n The structure of a reader process do { wait (mutex) ; readcount ++ ; if (readercount == 1) wait (wrt) ; signal (mutex) // reading is performed wait (mutex) ; readcount - - ; if redacount == 0) signal (wrt) ; signal (mutex) ; } while (true) Operating System Concepts 6. 55 Silberschatz, Galvin and Gagne © 2005

Dining Philosopher Problem n Have three state : eat, hungry and thinking n Two binary semaphore : mutex and s[i] n At first, set all state as hungry, mutex as 1, and s[i] =0 n Before taking the chopstick, set state as hungry n Before taking the chopstick, make sure that no neighbour is in eating state n Proceed to new state : eating Operating System Concepts 6. 56 Silberschatz, Galvin and Gagne © 2005

n Grab the first chopstick and make sure that no neighbour use them n Eat. When finish let go the chopstick n To let go the chopstick, enter new state: thinking n Check if the neighbour state is hungry and the left and the right neighbour is not eating. If so, put down chopstick Operating System Concepts 6. 57 Silberschatz, Galvin and Gagne © 2005

One possible solution Shared: int state[5], semaphore s[5], semaphore mutex; Init: mutex = 1; s[i] = 0 for all i=0. . 4 Philosopher i do { take_fork(i); /* eat */ put_fork(i); /* think */ } while(true); Operating System Concepts take_fork(i) { P(mutex); state[i] = hungry; test(i); V(mutex); P(s[i]); } put_fork(i) { P(mutex); state[i] = thinking; test((i+1)%N); test((i-1+N)%N); V(mutex); } 6. 58 test(i) { if(state[i] == hungry && state[(i+1)%N] != eating && state[(i-1+N)%N != eating) { state[i] = eating; V(s[i]); } Silberschatz, Galvin and Gagne © 2005

Problems with Semaphores n Correct use of semaphore operations: l signal (mutex) …. wait (mutex) l wait (mutex) … wait (mutex) l Omitting of wait (mutex) or signal (mutex) (or both) Operating System Concepts 6. 59 Silberschatz, Galvin and Gagne © 2005

Monitors n A high-level abstraction that provides a convenient and effective mechanism for process synchronization n Only one process may be active within the monitor at a time monitor-name { // shared variable declarations procedure P 1 (…) { …. } … procedure Pn (…) {……} Initialization code ( …. ) { … } } Operating System Concepts 6. 60 Silberschatz, Galvin and Gagne © 2005

Schematic view of a Monitor Operating System Concepts 6. 61 Silberschatz, Galvin and Gagne © 2005

Condition Variables n condition x, y; n Two operations on a condition variable: l x. wait () – a process that invokes the operation is suspended. l x. signal () – resumes one of processes (if any) tha invoked x. wait () Operating System Concepts 6. 62 Silberschatz, Galvin and Gagne © 2005

Monitor with Condition Variables Operating System Concepts 6. 63 Silberschatz, Galvin and Gagne © 2005

Solution to Dining Philosophers monitor DP { enum { THINKING; HUNGRY, EATING) state [5] ; condition self [5]; void pickup (int i) { state[i] = HUNGRY; test(i); if (state[i] != EATING) self [i]. wait; } void putdown (int i) { state[i] = THINKING; // test left and right neighbors test((i + 4) % 5); test((i + 1) % 5); } Operating System Concepts 6. 64 Silberschatz, Galvin and Gagne © 2005

Solution to Dining Philosophers (cont) void test (int i) { if ( (state[(i + 4) % 5] != EATING) && (state[i] == HUNGRY) && (state[(i + 1) % 5] != EATING) ) { state[i] = EATING ; self[i]. signal () ; } } initialization_code() { for (int i = 0; i < 5; i++) state[i] = THINKING; } } Operating System Concepts 6. 65 Silberschatz, Galvin and Gagne © 2005

Synchronization Examples n Solaris n Windows XP n Linux n Pthreads Operating System Concepts 6. 66 Silberschatz, Galvin and Gagne © 2005

Solaris Synchronization n Implements a variety of locks to support multitasking, multithreading (including real-time threads), and multiprocessing n Uses adaptive mutexes for efficiency when protecting data from short code segments n Uses condition variables and readers-writers locks when longer sections of code need access to data n Uses turnstiles to order the list of threads waiting to acquire either an adaptive mutex or reader-writer lock Operating System Concepts 6. 67 Silberschatz, Galvin and Gagne © 2005

Windows XP Synchronization n Uses interrupt masks to protect access to global resources on uniprocessor systems n Uses spinlocks on multiprocessor systems n Also provides dispatcher objects which may act as either mutexes and semaphores n Dispatcher objects may also provide events l An event acts much like a condition variable Operating System Concepts 6. 68 Silberschatz, Galvin and Gagne © 2005

Linux Synchronization n Linux: l disables interrupts to implement short critical sections n Linux provides: l semaphores l spin locks Operating System Concepts 6. 69 Silberschatz, Galvin and Gagne © 2005

Pthreads Synchronization n Pthreads API is OS-independent n It provides: l mutex locks l condition variables n Non-portable extensions include: l read-write locks l spin locks Operating System Concepts 6. 70 Silberschatz, Galvin and Gagne © 2005

Latihan 1. Apa yang dimaksud terminoilogi dibawah : l Atomic operation, l critical section, l deadlock, l mutual execlusion, l race condition, l starvation Operating System Concepts 6. 71 Silberschatz, Galvin and Gagne © 2005

2. Jelaskan 3 masalah yang dihadapi sinkronisasi berikut beserta bagaimana persoalan ini diatasi : l Bounded l Reader l Dining Operating System Concepts buffer problem, writer problem philosopher table 6. 72 Silberschatz, Galvin and Gagne © 2005

3. Selain menggunakan algoritma, sinkronisasi dilakukan secara hardware dengan (1) instruksi test and set dan (2) instruksi swap. Apa yang menyebabkan cara kedua yang lebih sering dipakai ? 4. Pada semaphore digunakan 2 operasi yaitu wait() and signal(). Apa fungsinya ? 5. Bagaimana condition variable mengatasi masalah yang dihadapi semaphore Operating System Concepts 6. 73 Silberschatz, Galvin and Gagne © 2005

End of Chapter 6

n http: //www. cs. cmu. edu/~gkesden/412 -18/fall 01/ln/lecture 7. html n http: //www. sal. ksu. edu/faculty/tim/ossg/IPC_sync/sync_requiremen ts. html n http: //cs. smith. edu/~thiebaut/Art. Of. Assembly/CH 19 -13. html n http: //williamstallings. com/OS/Animations. html Operating System Concepts 6. 75 Silberschatz, Galvin and Gagne © 2005