Process Synchronization

1. Process Synchronization

2. Definition • The term process is a generic term for both a process and a thread • Processes that do not interact are independent processes • Process synchronization is a generic term for the techniques used to delay and resume processes to implement process interactions

3. Race Condition • Uncoordinated accesses to shared data may affect consistency of data • Consider processes Piand Pjthat update the value of dsthrough operations aiand aj, respectively: Operation ai: ds:= ds+ 10; Let fi(ds) represent its result Operation aj: ds:= ds+ 5; Let fj(ds) represent its result • What situation could arise if they execute concurrently?

4. Why Synchronization • Concurrent access to shared data may result in data inconsistency. • Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes.

5. Producer Consumer Problem • solution must satisfy the following: • A producer must not overwrite a full buffer • A consumer must not consume an empty buffer • Producers and consumers must access buffers in a mutually exclusive manner • (Optional)Information must be consumed in the same order in which it is put into the buffers

6. Producer Consumer Problem(Cont..) • Shared data typeitem = … ; varbufferarray [0..n-1] of item; in, out: 0..n-1; counter: 0..n; in, out, counter := 0; • Producer process while(true) { … produce an item in nextp … while (counter == n); // do no-op; buffer [in] := nextp; in := in + 1 modn; counter := counter +1; }

7. Producer Consumer Problem (Cont..) • Consumer process while(true) { while (counter = =0 ); //dono-op; nextc := buffer [out]; out := out + 1 modn; counter := counter – 1; … consume the item in nextc … } • The statements: • counter := counter + 1; • counter := counter - 1; must be executed atomically.

8. Critical Section Problem • n processes all competing to use some shared data • Each process has a code segment, called critical section, in which the shared data is accessed. • Problem – ensure that when one process is executing in its critical section, no other process is allowed to execute in its critical section. • Structure of process Pi

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

10. Initial Attempt • Only 2 processes, P0 and P1 • General structure of process Pi(other process Pj) repeat entry section critical section exit section reminder section untilfalse; • Processes may share some common variables to synchronize their actions.

11. Algorithm 1

12. Algorithm 2

13. Algorithm 3 (Peterson’s Solution) • Combined shared variables of algorithms 1 and 2. • Process Pi Meets all three requirements; solves the critical-section problem for two processes.

14. Semaphore • Synchronization tool that does not require busy waiting. • Semaphore S – integer variable • can only be accessed via two indivisible (atomic) operations • wait (S) { while S <= 0 ; // no-op S--; } • signal (S) { S++; }

15. Critical section for n Processes

16. Semaphore Implementation • Define a semaphore as a record typesemaphore = record value: integer L: list ofprocess; end; • Assume two simple operations: • block suspends the process that invokes it. • wakeup(P) resumes the execution of a blocked process P.

17. Implementation(Cont..) • Semaphore problem: Busy waiting. Process waiting to enter CS loop continuously wasting CPU Cycles called Spin lock. • Modification: Waiting process places itself in waiting queue associated with semaphore. block(), wakeup(). • Implementation of wait: wait(semaphore *S) { S->value- -; if (S->value < 0) { add this process to S->list; block(); } } • Implementation of signal: signal(semaphore *S) { S->value++; if (S->value <= 0) { remove a process P from S->list; wakeup(P); } }

18. Producer Consumer Problem • N buffers, each can hold one item • Semaphore mutex initialized to the value 1 • Semaphore full initialized to the value 0 • Semaphore empty initialized to the value N

19. Producer Consumer Problem(Cont..) • The structure of the producer process do { // produce an item in nextp wait (empty); wait (mutex); // add the item to the buffer signal (mutex); signal (full); } while (TRUE);

20. Producer Consumer Problem(Cont..) • The structure of the consumer process do { wait (full); wait (mutex); // remove an item from buffer to nextc signal (mutex); signal (empty); // consume the item in nextc } while (TRUE);

21. Reader Writer Problem • A data set is shared among a number of concurrent processes • Readers – only read the data set; 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 • Several variations of how readers and writers are treated – all involve priorities • Shared Data • Data set • Semaphore mutex initialized to 1 • Semaphore wrt initialized to 1 • Integer readcount initialized to 0

22. Reader Writer Problem • The structure of a reader process do { wait (mutex) ; readcount ++ ; if (readcount == 1) wait (wrt) ; signal (mutex) // reading is performed wait (mutex) ; readcount - - ; if (readcount == 0) signal (wrt) ; signal (mutex) ; } while (TRUE); • The structure of a writer process do { wait (wrt) ; // writing is performed signal (wrt) ; } while (TRUE);

23. Dining Philosophers Problem • Philosophers spend their lives thinking and eating • Don’t interact with their neighbors, occasionally try to pick up 2 chopsticks (one at a time) to eat from bowl • Need both to eat, then release both when done • In the case of 5 philosophers • Shared data • Bowl of rice (data set) • Semaphore chopstick [5] initialized to 1

24. Dining Philosophers Problem(Cont..) • The structure of Philosopheri: do { wait ( chopstick[i] ); wait ( chopStick[ (i + 1) % 5] ); // eat signal ( chopstick[i] ); signal (chopstick[ (i + 1) % 5] ); // think } while (TRUE);

25. Monitors • A monitor type resembles a class in a language like C++ or Java • Contains declarations of shared data • Only one process may be active within the monitor at a time. • Its procedures encode operations that manipulate shared data and implement process synchronization • A condition is a situation of interest in a monitor • A condition variable is associated with a condition • A process executing a wait operation on condition variable is blocked until some process performs a signal operation.

26. Structure of Monitor typemonitor-name = monitor variable declarations procedure entryP1 :(…); begin … end; procedureentryP2(…); begin … end;  procedure entryPn (…); begin…end; begin initialization code end

27. Condition Variables • To allow a process to wait within the monitor, a condition variable must be declared, as varx, y: condition • Condition variable can only be used with the operations wait and signal. • The operation x.wait;means that the process invoking this operation is suspended until another process invokes x.signal; • The x.signal operation resumes exactly one suspended process. If no process is suspended, then the signal operation has no effect

28. View of a Monitor

29. Example Reader Writer Problem