Process Synchronization

Process Synchronization

Process Synchronization Module 5: Process Synchronization • Background • The Critical-Section Problem • Peterson’s Solution • Synchronization Hardware • Semaphores • Classic Problems of Synchronization • Monitors • Synchronization Examples

Process Synchronization Background • Concurrent access to shared data may result in data inconsistency • Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes • Suppose that we wanted to provide a solution to the producer-consumer 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.

Process Synchronization Producer while (true) /* produce an item and put in nextProduced while (count == BUFFER_SIZE) ; // do nothing buffer [in] = nextProduced; in = (in + 1) % BUFFER_SIZE; count++; } • count++ could be implemented asregister1 = count register1 = register1 + 1 count = register1

Process Synchronization Consumer while (1) { while (count == 0) ; // do nothing nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; count--; /* consume the item in nextConsumed } • count-- could be implemented as register2 = count register2 = register2 - 1 count = register2

Process Synchronization Race Condition • Consider this execution interleaving with “count = 5” initially: S0: producer execute register1 = count {register1 = 5}S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = count {register2 = 5} S3: consumer execute register2 = register2 - 1 {register2 = 4} S4: producer execute count = register1 {count = 6 } S5: consumer execute count = register2 {count = 4} • Consider this execution interleaving with “count = 5” initially: S0: producer execute register1 = count {register1 = 5}S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = count {register2 = 5} S3: consumer execute register2 = register2 - 1 {register2 = 4} S4: consumer execute count = register2 {count = 4} S5: producer execute count = register1 {count = 6 } • If several processes are manipulating the same data concurrently, the outcome of the execution depends upon the particular order in which the access takes place • This situation is called a race condition

Process Synchronization Module 6: Process Synchronization • Background • The Critical-Section Problem • Peterson’s Solution • Synchronization Hardware • Semaphores • Classic Problems of Synchronization • Monitors • Synchronization Examples • Atomic Transactions

Critical section – section of code changing common variables, updating a table or writing a file Requirement for the system – the execution of critical sections by the processes must be mutually exclusive Critical section Problem - To design a protocol that the processes can use to cooperate so as to allow execution of critical sections by the processes in mutually exclusive manner. General structure of a typical process A. do { | entry section I request critical section I exit section I remainder section } while (TRUE); Process Synchronization Critical Section Problem

Process Synchronization Requirements for solution to Critical-Section Problem • Mutual Exclusion - If process Pi is executing in its critical section, then no other processes can be executing in their critical sections. • Progress - If no process is executing in its critical section some processes wish to enter only processes which are not executing in its remainder section can make decision and the selection cannot be postponed indefinitely • Bounded Waiting - A bound on the number of times that other processes are allowed to enter their critical sections after a process, Pi has made a request to enter before that request is granted • Assume that each process executes at a nonzero speed • No assumption concerning relative speed of the N processes

Process numbered P0 and P1 Algorithm 1- common variable turn initialized to 0 or 1 if turn ==i, Process Pi is allowed to execute in its critical section (states which process is allowed) Process Synchronization Two-Process Solutions Process Pj [P1 ] do { while ( turn !=j);// Pi is not ready CRITICAL SECTION turn = i; REMAINDER SECTION }while(1) Process Pi [P0 ] do { while ( turn != i );//Pj is not ready CRITICAL SECTION turn = j; REMAINDER SECTION }while(1) Solution does not provide Progress Requirement

Process numbered P0 and P1 Algorithm 1- common variable turn initialized to 0 or 1 if turn ==i, Process Pi is allowed to execute in its critical section (states which process is allowed) Process Synchronization Two-Process Solutions Process [P1] do { while ( turn !=1) { };// Pi is not ready CRITICAL SECTION turn = 0; REMAINDER SECTION }while(1) Process [P0] do { while ( turn != 0 ) { } ;//Pj is not ready CRITICAL SECTION turn = 1; REMAINDER SECTION }while(1) Solution does not provide Progress Requirement

Algorithm 2 – It remembers also the state of the process whether it has made a request Uses boolean variable flag[2] initialized to 0 If flag[i] is true, denotes Pi is ready to enter into its critical section. Process Synchronization Two-Process Solutions Process Pj [P1 ] do { flag[j] = true; while (flag[i]); //Pi is not ready to enter CRITICAL SECTION flag[j] = false; REMAINDER SECTION } while(1) Process Pi [P0 ] do { flag[i] = true; while (flag[j]) { }; //Pj is not ready to enter CRITICAL SECTION flag[i] = false; REMAINDER SECTION } while(1)

Algorithm 2 – Solution does not provide Progress Requirement As the following execution sequence [P0 ]sets flag[0] = true; then [P1 ]sets flag[1] = true; Causes both the processes looping forever in their respective while loops Process Synchronization Two-Process Solutions

Process Synchronization Peterson’s Solution / Algorithm 3 • Assumptions- The LOAD and STORE instructions are atomic; that is, cannot be interrupted. • The two processes share two variables: • int turn; • Boolean flag[2] • The variable turn indicates whose turn it is to enter the critical section. • The flag array is used to indicate if a process is ready to enter the critical section. • flag[i] = true implies that process Pi is ready!

Process Synchronization Algorithm for Processes Process Pj do { flag[j] = TRUE; turn = i; while ( flag[i] && turn == i); CRITICAL SECTION flag[j] = FALSE; REMAINDER SECTION } while (TRUE); Process Pi do { flag[i] = TRUE; turn = j; while ( flag[j] && turn == j); CRITICAL SECTION flag[i] = FALSE; REMAINDER SECTION } while (TRUE); • The eventual value of turn decides which will enter CS first • It is correct solution meeting all the requirements

For n processes, the solution is called bakery algorithm. • Each Process wishing to enter into CS is given a number. Only the process with least number is allowed. • If two processes receive the same number their name is compared to break the tie. • Data structures used are • boolean choosing[n] initialized to false • Int number[n] initialized to 0 • As the processes enter into CS on FCFS basis, it satisfies all its requirements Process Synchronization Multiple-Process CS Solutions

do { choosing[i] = true; number[i] = max(number[0], number[1],……. number[n-1]) +1; choosing[i] = false; for(j=0 ; j < n ; j++) { while(choosing[ j ]) { } ; while( (number[j] != 0) && (number[ j ], j) < (number[ i ], i) { }; // Do nothing till there is another process, Pj with smaller number than Pi } CRITICAL SECTION number[i] = 0; REMAINDER SECTION }while(1); Process Synchronization Process Piin the bakery algorithm

Process Synchronization Synchronization Hardware • Many systems provide hardware support for critical section code • Uniprocessors – could disable interrupts • Currently running code would execute without preemption • Generally too inefficient on multiprocessor systems • Modern machines provide special atomic hardware instructions • Atomic = non-interruptable • Two instructions may execute simultaneously but sequentially in arbitrary order on different CPU’s • Hardware Instructions used - • TestAndSet - Either test memory word and set value • Swap -Or swap contents of two memory words

Process Synchronization TestAndndSet Instruction Test what is lock, Set it to true And Return its previous value • Definition: boolean TestAndSet (boolean *target) { boolean rv = *target; *target = TRUE; return rv: }

Process Synchronization Solution using TestAndSet • Shared boolean variable lock., initialized to false. • The Lock value, if False specified that the resource is not being utilized by any process, if True then resource is in use so other processes have to wait, loop over • Solution: do { while ( TestAndSet (&lock )) ; /* do nothing CRITICAL SECTION lock = FALSE; REMAINDER SECTION } while ( TRUE);

Process Synchronization Swap Instruction Swap the boolean values At The locations specified by Parameters, a & b • Definition: void Swap (boolean *a, boolean *b) { boolean temp = *a; *a = *b; *b = temp: }

Process Synchronization Solution using Swap • Shared Boolean variable lock initialized to FALSE; Each process has a local Boolean variable key. • Solution: do { key = TRUE; while ( key == TRUE) Swap (&lock, &key ); // Keep swapping if lock is true CRITICAL SECTION lock = FALSE; REMAINDER SECTION } while ( TRUE); • Although these algorithms satisfy the mutual-exclusion requirement, they do not satisfy the bounded-waiting requirement.

Process Synchronization Semaphore • Synchronization tool that does not require busy waiting • Semaphore S – integer variable • Two standard atomic operations modify wait() – wishes to use a resource also written as P() and signal() – release a resource also written as V() • Originally called P() andV() from Dutch notation • The semaphore value in the wait() and signal() operations must be executed indivisibly • wait (S) { while S <= 0 ; // no-op S--; } • signal (S) { S++; } Use: Do { wait(mutex); CRITICAL SECTION signal(mutex); REMAINDER SECTION } while(1);

For example, consider two concurrently running processes: P1 with a statement S1 and P2 with a statement S2. Suppose we require that S2 be executed only after S1 has completed. Let P1 and P2 share a common semaphore synch, initialized to 0, and in process P1, S1; signal(synch) ; in process P2, wait(synch); S2; Process Synchronization Other use of semaphores

Process Synchronization Semaphore as General Synchronization Tool • Counting semaphore – integer value can range over an unrestricted domain ( number of resources available) • Binary semaphore – integer value can have value 0 or 1 Also known as mutex locks • Provides mutual exclusion- Semaphore S; // initialized to 1 • wait (S); Critical Section signal (S); • Can implement a counting semaphore S as a binary semaphore

Process Synchronization Semaphore Implementation • Main Advantage of Semaphore? - To overcome the need for busy waiting, which is not adequate for uniprocessor systems, the process can use semaphore and block itself. • Executed indivisibly - Must guarantee that no two processes can execute wait () and signal () on the same semaphore at the same time • Thus, implementation becomes the critical section problem where the wait and signal code are placed in the critical section. • But implementation code is short • Little busy waiting if critical section rarely occupied

Process Synchronization Semaphore Implementation with no Busy waiting • With each semaphore there is an associated waiting queue. Each entry in a waiting queue has two data items: • value (of type integer) • pointer to next record in the list • Definition in C- typedef struct { int value; // semaphore value struct process *list; // List of waiting processes // which have to wait for resource } semaphore; • Two operations: • Block() – place the process, P invoking the operation on the appropriate waiting queue.(adds ) • Wakeup() – remove one of processes in the waiting queue and place it in the ready queue.(remove)

Process Synchronization Semaphore Implementation with no Busy waiting(Cont.) • Implementation of wait: wait (S) { value--; if (value < 0) { add this process to waiting queue block(); } // suspends the process that invokes it } • Implementation of signal: Signal (S) { value++; if (value <= 0) { remove a process P from the waiting queue wakeup(P); //resumes the execution of the blocked process P } } • Basis : No two processes can execute the wait() and signal() operations on same semaphore at the same time

Process Synchronization Deadlock and Starvation • Implementation of a semaphore with waiting queue may result into deadlock • Deadlock : It is a situation where two or more processes are waiting indefinitely for an event that can be caused by only one of the waiting processes • Let S and Q be two semaphores initialized to 1 P0P1 wait (S); 1 wait (Q); 2 wait (S); // blocked // blocked wait (Q); . . Critical Section. Critical Section. . . signal (S); signal (Q); signal (Q); signal (S); • Starvation – indefinite blocking. A process may never be removed from the semaphore queue, where it was added when it was suspended in wait(). (LIFO order)

Process Synchronization Classical Problems of Synchronization • Bounded-Buffer Problem • Readers and Writers Problem • Dining-Philosophers Problem

Process Synchronization Bounded-Buffer Problem • N buffers, each can hold one item • Semaphore mutex initialized to the value 1- For mutual exclusion between two processes • Semaphore full initialized to the value 0 – Denoting none buffer items are full till now. • Semaphore empty initialized to the value N – Denoting N buffer items are empty till now.

Process Synchronization Bounded Buffer Problem (Cont.) • The structure of the Producer process do { // produce an item wait (empty); // decrement the no. of empty buffers wait (mutex); // add the item to the buffer signal (mutex); signal (full); // increment the no. of full buffers } while (true);

Process Synchronization Bounded Buffer Problem (Cont.) • The structure of the consumer process do { wait (full); // decrement the no. of full buffers wait (mutex); // remove an item from buffer signal (mutex); signal (empty); // increment the no. of empty buffers // consume the removed item } while (true);

Process Synchronization Readers-Writers Problem • A data object is shared among a number of concurrent processes • Readers – only read the data object; they do not perform any updates • Writers – can both read and write. • Problem – allow multiple readers to read at the same time. Only one single writer can access the shared data at the same time. • Based on priorities, there are 2 forms of readers-writers problem: • No reader kept waiting until the writer has obtained permission to use the shared object • No writer kept waiting : Once a writer is ready, that writer performs its write as soon as possible & no new readers may start reading.

1st Form - For no reader kept waiting until the writer has obtained permission to use the shared object. Only after all readers finish reading, writers are allowed to write. • 2nd Form - For no writer kept waiting until there is another writer which has obtained permission to write. If readers are reading then writer gets the chance to write immediately after they complete and no new readers entertained. • Shared Data • Shared data object • Semaphore mutex initialized to 1. It is used to ensure mutual exclusion when the variable readcount is updated. (For reader process only) • Semaphore wrt initialized to 1. It functions as a mutual -exclusion semaphore for the writers. (Used by both processes) • Integer readcount initialized to 0. The readcount variable keeps track of how many processes are currently reading the object. Process Synchronization Readers-Writers Problem (Cont.)

Process Synchronization Readers-Writers Problem- 1st Form 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) Writer process do { wait (wrt) ; // writing is performed and so wrt made 0 signal (wrt) ; } while (true) Multiple readers allowed to read at the same time Multiple writers can’t write at the same time

Process Synchronization Dining-Philosophers Problem • Shared data • Bowl of rice (data set) • Semaphore chopstick [5] initialized to 1 • As usual wait() to grab the chopstick and signal() to release

Process Synchronization Dining-Philosophers Problem (Cont.) • The structure of Philosopher i for no two neighbors eating simultaneously, Do { wait ( chopstick[i] ); wait ( chopstick[ (i + 1) % 5] ); // eat signal ( chopstick[i] ); signal (chopstick[ (i + 1) % 5] ); // think } while (true) ; • It has the possibility of creating a deadlock.

Process Synchronization Problems with Semaphores • Incorrect use of semaphore operations: • signal (mutex) …. wait (mutex) //multiple processes in CS • wait (mutex) … wait (mutex) // deadlock will occur • Omitting of wait (mutex) or signal (mutex) (or both) • Use high level synchronization construct • Conditional Critical region • Monitors

In your mind ? Any Questions

Process Synchronization