Synchronization and semaphores

1
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
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 I1 and I I-1 and write(I)
• write(I)
• Both first and second write can be 0, 1 or 2.
  Why?

3
Parallel soup

• (1) I I1 and (2) I I-1 and (3) write(I)
• (4) write(I)
• If execution order is (1)(2)(3)(4), output is
  lt1,1gt
• If execution order is (1)(3)(2)(4), output is
  lt2,1gt
• If execution order is (2)(3)(1)(4), output is
  lt0,1gt
• How to get second write of 0
• (1) II1 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) II-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 lt2,2gt
• If II-1 is executed first, we could get lt0,0gt,
  etc.

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
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 I1 wakeup(A)
• and block(A) I I-1 wakeup(A)
• and block (A) write(I) wakeup(A)
• write(I)
• Output Second write is always I1, but first
  write can be 0, 1 or 2, depending upon which and
  statement executes first.

6
Semaphores

• 2. P-V semaphores (Dijkstra).
• P(X) If Xgt 0 continue, else wait until X gt 0.
• X X-1 (in unit time)
• V(X) X X1 (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
  Vcounter
• In GetBuffer, if no buffers are available, the
  program will wait until some other process issues
  a FreeBuffer to unfreeze the blocked process.

7
Disadvantages of Semaphore

• A task can wait for only one semaphore at a time
• Dead lock
• Difficult to understand, debug and verify
• Only work in shared memory

8
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 loop P3 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.

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

10
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) ...

11
Ada rendezvous

• select
• when Device1Status ON gt accept Ready1 do .
  . .
• end
• or when Device2Status ON gt accept Ready2 do .
  . .
• end
• or when Device3Status connected gt 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

12
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