1. PZ12B Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, 2000 1 PZ12B - Synchronization and semaphores Programming Language Design and Implementation (4th Edition) by T. Pratt and M. Zelkowitz Prentice Hall, 2001 Section 11.2.4-11.2.5

2. PZ12B Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, 2000 2 Issues in synchronization Easy to do - Context switching (and statement, fork() function, task creation) Hardware virtual memory makes it easy for operating system to create independently executing tasks in their own address space Hard to do - Synchronization. How to pass information reliably among a set of independently executing parallel tasks. Consider and statement discussed previously: What is output that is printed? I = 1; I = I+1 and I = I-1 and write(I); write(I) Both first and second write can be 0, 1 or 2. Why?

3. PZ12B Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, 2000 3 Parallel soup (1) I = I+1 and (2) I = I-1 and (3) write(I); (4) write(I) If execution order is (1)(2)(3)(4), output is If execution order is (1)(3)(2)(4), output is If execution order is (2)(3)(1)(4), output is How to get second write of 0: (1) I=I+1 is not a single operation. It is usually 3 instructions: Load from I, Add 1, store into I. What if context switch between instructions 1 and 2? (2) I=I-1 will set I to 0 then context switch back to (1) causes original value of I to be incremented to 2, which is printed as If I=I-1 is executed first, we could get, etc.

4. PZ12B Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, 2000 4 Critical regions A critical region is a sequence of program statements within a task where the task is operating on some data object shared with other tasks. Must use some mechanism to access this data: Semaphores Messages Monitors Rendezvous

5. PZ12B Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, 2000 5 Mutual exclusion 1. Mutual exclusion - Only one process can be executing a given section of code at one time. block(X) - block semaphore X. wakeup(X) - unblock semaphore X block(x) - if x is free, grab x, else wait until it is free wakeup(x) - free x and start any process waiting on x Example again: I = 1; block(A); I = I+1; wakeup(A) and block(A); I = I-1; wakeup(A) and block (A); write(I); wakeup(A) write(I) Output: Second write is always I=1, but first write can be 0, 1 or 2, depending upon which and statement executes first.

6. PZ12B Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, 2000 6 Semaphores 2. P-V semaphores (Dijkstra). P(X) { If X> 0 continue, else wait until X > 0. X = X-1 (in unit time)} V(X) { X = X+1 (in unit time)} P acts as a gate to limit access to tasks. In addition, you can use the semaphore as a counter to control how much access you need. Buffer manager: Initialization:{ counter = number of buffers available}; GetBuffer: { P(counter}, return buffer and process data}; FreeBuffer: { Put buffer on free list; V{counter}}; In GetBuffer, if no buffers are available, the program will wait until some other process issues a FreeBuffer to unfreeze the blocked process.

7. PZ12B Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, 2000 7 Multiple address spaces P-V assume all semaphores are addressable by all waiting tasks. When processes execute in different address spaces (e.g., on different machines), semaphores don't work. Messages can be used: send(A) - Send a message to pipe A. receive(A) - Receive a message on pipe A. If no pending message, wait until one shows up. Sample Input-Process-Output loop: P1: do loop P2: do loopP3: do loop Get data; Receive(P2, data) Receive(P3, data); Send(P2,data); Process data; Print data end Send(P3, data) end end Synchronization can be handled by sending messages in both directions: Pipe AB sends from A to B. Pipe BA sends from B to A.

8. PZ12B Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, 2000 8 Problem: Deadlock Process A: Block(X); Block(Y);... Do something Wakeup(X); Wakeup(Y); Process B: Block(Y); Block(X);... Do something Wakeup(X); Wakeup(Y) If process A does Block(X) at same time process B does Block(Y), then Both will succeed and then Both will wait for the other resource forever An unlikely occurrence, but it CAN happen.

9. PZ12B Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, 2000 9 Synchronization in Ada Rendezvous in Ada: Sender issues call DataReady Receiver issues accept DataReady. Either waits for other to reach this point. accept DataReady do -- Entry point for task for sender to do call DataReady -- process synchronization taask end; How to prevent receiver of task to be blocked- Use guarded if (select statement)...

10. PZ12B Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, 2000 10 Ada rendezvous select when Device1Status = ON => accept Ready1 do... end; or when Device2Status = ON => accept Ready2 do... end; or when Device3Status = connected => accept Ready3 do... end; else... -- No device is ready; do something end select; rendezvous - Task waits for either of Device 1, 2, or 3, and if none are ON, does something else

11. PZ12B Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, 2000 11 Monitors A monitor is a shared data object together with the set of operations that may manipulate it (i.e., an abstract data type) A task may manipulate the shared data object only by using the defined operations (i.e., data is encapsulated) To enforce mutual exclusion, require that at most one of the operations defined for the data object may be executing at any given time. We could implement monitors in Java or C++ as classes