Chapter 2.3 : Interprocess Communication

1. Chapter 2.3 : Interprocess Communication • Process concept  • Process scheduling  • Interprocess communication • Deadlocks • Threads

2. Produce Get from buffer Put in buffer Consume Producer - Consumer Problem Producer Process • Buffer is shared (ie., it is a shared variable) Consumer Process BUFFER

3. p1 1 p2 2 p3 3 p4 4 Buffer Consumer 1 2 c2 t Progress in time….. Producer • Both processes are started at the same time and consumer uses some old value initially 3 instead of 2! c1

4. A Race Condition • Because of the timing and which process starts first • There is a chance that different executions may end up with different results

5. Critical Sections • Critical Section • A section of code in which the process accesses and modifies shared variables • Mutual Exclusion • A method of preventing for ensuring that one (or a specified number) of processes are in a critical section

6. Why Processes Need to Communicate? • To synchronize their executions • To exchange data and information

7. Rules to Form Critical Sections 1. No two processes may be simultaneously inside their CS (mutual exclusion) 2. No assumptions are made about relative process speeds or number of CPUs 3. A process outside a CS should not block other processes 4. No process should wait forever before entering its CS

8. Mutual Exclusion Problem : Starvation • Also known as Indefinite Postponement • Definition • Indefinitely delaying the scheduling of a process in favour of other processes • Cause • Usually a bias in a systems scheduling policies (a bad scheduling algorithm) • Solution • Implement some form of aging

9. Another Problem : Deadlocks • Two (or more) processes are blocked waiting for an event that will never occur • Generally, A waits for B to do something and B is waiting for A • Both are not doing anything so both events never occur

10. How to Implement Mutual Exclusion • Three possibilities • Application: programmer builds some method into the program • Hardware: special h/w instructions provided to implement ME • OS: provides some services that can be used by the programmer • All schemes rely on some code for • enter_critical_section, and • exit_critical_section • These "functions" enclose the critical section

11. Application Mutual Exclusion • Application Mutual Exclusion is • implemented by the programmer • hard to get correct, and • very inefficient • All rely on some form of busy waiting (process tests a condition, say a flag, and loops while the condition remains the same)

12. Example • Producer produce If lock = 1 loop until lock = 0 lock=1 put in buffer lock=0 • Consumer If lock = 1 loop until lock = 0 lock=1 get from buffer lock=0 Consume • Note: initially lock = 0

13. Dekker’s Algorithm Program Dekker; Var turn : integer; wantp, wantq :boolean; Procedure p; Begin repeat wantp := true; while wantq do if turn = 2 then begin wantp:= false; repeat until turn = 1; wantp:=true end; CS; turn := 2; wantp:= false; NCS; until false; End; Procedure q; Begin repeat wantq2 := true; while wantp do if turn = 1 then begin wantq:= false; repeat until turn = 2; wantq:=false end; CS; turn := 1; wantq := false; NCS; until false; End; Begin (* main program *) turn:= 1; wantp:= false; wantq:= false; cobegin p; q coend End.

14. Explanation of the Algorithm Procedure p; Begin repeat wantp := true;(* 1 *) while wantq do if turn = 2 then begin wantp:= false; repeat until turn = 1; wantp:=true end;(* 2 *) CS; turn := 2;(* 3 *) wantp := false;(* 4 *) NCS; until false; End; • Process makes a request to enter CS • If the other process had made a request to enter CS before and if it is its turn then • Take back the request to enter CS by setting the “want” variable to false” • Wait for the other process to exit CS and change the turn variable • Make a new request to enter CS and then enter CS • Flip the turn variable so that now the other process can enter CS • Set “want” variable to false to indicate that the process is now out of CS

15. Comments • Explicit control of transfer by a turn variable. Hence; turn = 1 means P’s turn, turn = 2 Q’s turn • If a process is blocked, the other process can still go • Dekker’s algorithm is correct (prove it!) • It satisfies the mutual exclusion property • It is free from deadlock and starvation

16. Hardware ME : Test and Set Instruction • Perform an indivisible x:=r and r:=1 • x is a local variable • r is a global register set to 0 initially • repeat (test&set(x)) until x = 0; < critical section > r:= 0;

17. Hardware ME : Exchange Instruction • Exchange: swap the values of x and r • x is a local variable • r is a global register set to 1 initially • x:= 0; repeat exchange(r, x) until x = 1; < critical section > exchange(r, x); Note: r:= 0 and x:= 1 when the process isin CS

18. Another Hardware ME : Disabling Interrupts • On a single CPU only one process is executed • Concurrency is achieved by interleaving execution (usually done using interrupts) • If you disable interrupts then you can be sure only one process will ever execute • One process can lock a system or degrade performance greatly

19. Hardware ME Characteristics • Advantages • can be used by a single or multiple processes (with shared memory) • simple and therefore easy to verify • can support multiple critical sections • Disadvantages • busy waiting is used (very important) • starvation is possible • deadlock is possible (especially with priorities)

20. Mutual Exclusion Through OS • Semaphores • Message passing

21. Semaphores • Major advance incorporated into many modern operating systems (Unix, OS/2) • A semaphore is • a non-negative integer • that has two indivisible, valid operations

22. Semaphore Operations • Wait(s) If s > 0 then s:= s - 1 else block this process • Signal(s) If there is a blocked process on this semaphore then wake it up else s:= s + 1

23. More on Semaphores • The other valid operation is initialisation • Two types of semaphores • binary semaphores can only be 0 or 1 • counting semaphores can be any non-negative integer • Semaphores are an OS service implemented using one of the methods shown already • usually by disabling interrupts for a very short time

24. Producer - Consumer Problem: Solution by Semaphores • Initially semaphore mutex is 1 Produce Wait(mutex) Put in buffer Signal(mutex) Wait(mutex) Get from buffer Signal(mutex) Consume CS

25. Process A Process B Process C think(); draw_A(); think(); draw_B(); think(); draw_C(); Another Example • Three processes all share a resource on which • one draws an A • one draws a B • one draws a C • Implement a form of synchronization so that the output appears ABC

26. Process A Process B Process C think(); draw_A(); signal(b); wait(b); think(); draw_B(); signal(c); wait(c); think(); draw_C(); • Semaphore b = 0, c = 0;

27. Dining Philosophers • 5 seating places, 5 plates of spagetti and 5 forks • A philosophers life cycle Repeat think; eat forever • Eating can only be done with 2 forks • Devise a ritual (protocol) that will allow the philosophers to eat. The protocol should satisfy mutual exclusion(no two philosophers try to use the same fork simultaneously) , free from deadlock and absense of starvation Figure is from Modern OS by Tanenbaum

28. Dining Philosophers Solution – First Attempt Program diningphilosophers; Var i : integer; fork : array[0..4] of semaphore; Procedure philosopher (i : integer); Begin repeat think; wait(fork[i]); (* get left fork *) wait(fork[(i+1) mod 5]; (* get right fork *) eat; signal(fork[i]); (* return left fork *) signal(fork[(i+1) mod 5]; (* return right fork *) until false; End; Begin (* main *) for i:= 0 to 4 do fork[i]:= 1; (* initially all forks are available *) cobegin philosopher(0); philosopher(1); philosopher(2); philosopher(3); philosopher(4); coend; End.

29. Comments on First Attempt • Mutual exclusion is implemented by a binary semaphore fork • Deadlock is possible if all 5 philosophers take the left forks simultaneously then all would wait for the right fork • How to handle the deadlock and ensure liveliness? • Let at the most 4 philosophers to sit and eat. • Two of them can eat, one holds a fork and the other just sits • One philosopher can eat and the other 3 can hold their left forks

30. Correct Solution Program diningphilosophers; Var fork : array[0..4] of semaphore; i : integer; table : semaphore; (* seating limit *) Procedure philosopher (i : integer); Begin repeat think; wait(table); wait(fork[i]); (* get left fork *) wait(fork[(i+1) mod 5]; (* get right fork *) eat; signal(fork[i]); (* return left fork *) signal(fork[(i+1) mod 5]; (* return right fork *) signal(table); until false; End; Begin (* main *) for i:= 0 to 4 do fork[i]:= 1; table:= 4; cobegin philosopher(0); philosopher(1); philosopher(2); philosopher(3); philosopher(4); coend; End.

31. Message Passing • Provides synchronization and information exchange • Message Operations: • send(destination, &message) • receive (source, &message)

32. Producer - Consumer Problem Using Messages #define N 100 /*number of message slots*/ producer( ) {int item; message m; while (TRUE) { produce_item(&item); receive(consumer,&m); build_message(&m, item); send(consumer,&m); }}

33. Consumer( ) {int item; message m; for (i=0; i<N; i++) send(producer,&m); while (TRUE) { receive(producer,&m); extract_item(&m,&item); send(producer,&m); consume_item(item); }}