1. Interprocess Communication & Synchronization
-Compiled by Sheetal for B. Sc CSIT
(Ref: Modern Operating System by AS Tanenbaum
Lecture noted of Prashant Shenoy)

2. Interprocess Communication
Three problems
How to actually do it
How to deal with process conflicts (2 airline reservations for same seat)
How to do correct sequencing when dependencies are present-aim the gun before firing it
SAME ISSUES FOR THREADS AS FOR PROCESSES-SAME SOLUTIONS AS WELL

3. Race Condition Two process reading and writing same data
Final results depends on who runs precisely
Difficult to debug

4. Synchronization Problem

5. Synchronization Terminology

11. Properties of a good solution
Mutual exclusion
No assumptions about speeds or number of CPU’s
No process outside critical region can block other processes
No starvation-no process waits forever to enter critical region .

12. What we are trying to do

13. First attempts-Busy Waiting
List of proposals to achieve mutual exclusion
Disabling interrupts
Lock variables
Strict alternation
Peterson's solution
The TSL instruction

14. Disabling Interrupts
Idea: process disables interrupts, enters cr, enables interrupts when it leaves cr
Problems
Process might never enable interrupts, crashing system
Won’t work on multi-core chips as disabling interrupts only effects one CPU at a time

15. Lock variables A software solution-everyone shares a lock
When lock is 0, process turns it to 1 and enters cr
When exit cr, turn lock to 0
Problem-Race condition

16. Lock variables Contd… P0 P1 Will this work?
To enter CR first check lock
If lock = 0, set lock =1 and enter CR
If lock =1 wait it till 0
( lock = 0 no process in CR, lock = 1 some process in CR) P0
if (lock =0) {
lock=1;
CRIRICAL REGION;
lock=0; } P1
if (lock =0) {
lock=1;
CRIRICAL REGION;
lock=0; }
Will this work?

17. Lock variables Problem
One process reads lock = 0
Before it set lock=1 next process scheduled
Next process set lock=1
Again first process scheduled and set lock=1
Two Process in Critical region
Won’t help if again you check lock before entering CR

18. Strict Alternation
Variable turn which is initially zero keeps track of whose turn it is to enter CR
Initally P0 isntect turn, find it to be 0 and enter CR
P1 Scheduled, find turn = 0, be in tight loop continuously testing turn to see when it becomes 1
Continuously testing variable until some value appear is called busy waiting
Lock that uses busy wait is called spin lock

19. Strict Alteration Problem
P0 leaves CR; turn =1
P1 enter CR, finish CR quickly, both on non CR; turn=0
P0 execute whole loop quickly, exiting CR setting turn=1
This point, turn=1, both process running non CR
Suddenly P0 finish it non CR goes back to top of loop
P0 is not permitted to enter CR because turn=1
Process 1 still busy with is non CR
P0 hangs on while loop until P1 set turn=1
Conclusion: VIOLATES condition 3
NOT good if one process is slower than other

20. Problems with strict alternation
Employs busy waiting-while waiting for the cr, a process spins
If one process is outside the cr and it is its turn, then other process has to wait until outside guy finishes both outside AND inside (cr) work

21. Peterson's Solution .

22. Peterson’s Solution
Before entering CR each process calls enter_region with its process number (0 or 1)
This call make wait till safe to enter
After finishing CR process call leave_region giving permission to enter other process

23. Peterson’s Solution algorithm trace
None the process in CR
Process 0 calls enter_region
Other = 1; interested[0]=TRUE; turn=0;
Process 1 calls enter_region
It will hang till interested[0] goes false – an event that only happen when process 0 calls leave_region

24. TSL
TSL reads lock into register and stores NON ZERO VALUE in lock (e.g. process number)
Reading the word and storing into it is conformed be indivisible. No other processor can access the memory word until instruction finished
The CPU execution the TSL instruction locks the memory bus to prohibit other CPU from accessing memory until it is dome

25. Using TSL
Shared Value LOCK is used
When lock=0, any process may set it to 1 using the TSL instruction and read write memory
When it is done, the process sets lock back to 0

26. Using TSL
enter_region: ; A "jump to" tag; function entry point.
tsl reg, lock ; Test and Set Lock; flag is theshared variable; it is copied
; into the register reg and lock then atomically set to 1.
cmp reg, # ; Was flag zero on entry_region?
jnz enter_region ; Jump to enter_region if reg is non-zero; i.e., lock was ;nonzero on entry.
ret ; Exit; i.e., flag was zero on entry. If we get here, tsl will have set ;it non-zero; thus ; we have claimed the resoure associated with ; return to caller CR entered
leave_region:
move lock, # ; store 0 in lock
ret ; return to caller
TSL is atomic. Memory bus is locked until it is finished executing.

27. Using TSL
First instruction copies old value of lock to the register then set lock=1
Old value is compared with 0
If it is non-zero, the lock already set, so the program just go back to beginning and tests again
When it become 0 (next process leaves CR), function returns with the lock set.
Clearing lock is done in leave_region routine

28. TSL vs Disabling Interrupt
Different than disabling interrupt
Disabling interrupt doesn’t prevent second processor on the bus from accessing the word between read and write
Instead to disabling interrupt TSL will lock the memory bus from hardware level which prohibit other CPU to access it

29. XCHG instruction
Xchg a,b exchanges a & b

30. What’s wrong with Peterson, TSL ,XCHG?
Though process is busy waiting still it is consuming CPU
Priority Inversion Problem
Two processes with Priority H for High, L for Low
Scheduling rule: H is run whenever it is ready
H blocked, L in CR again H become ready to run (I/O request Completed)
H now begins busy waiting, L is never scheduled while H is running, L never gets chance to leave CR
H loops forever

31. Sleep and Wakeup Busy waiting-waste of CPU time!
Idea: Replace busy waiting by blocking calls
Sleep blocks process
Wakeup unblocks process
Sleep and wakeup are system calls.
Also available in C library supporting system call

32. The Producer-Consumer Problem (aka Bounded Buffer Problem)
Two process Shares on fixed size buffer, one producer puts information, next consumer, takes it out
Problem 1
Producer wants to put new item when buffer full
Solution
Producer go to sleep, to be awakened consumer remove one or more item
Problem 2
Consumer want remove item when buffer is empty
Consumer go to sleep until producer put something in buffer and wakes it up
Seems simple but may lead race condition

33. The Producer-Consumer Problem (aka Bounded Buffer Problem)
. . .

34. The problem with sleep and wake-up calls
Empty buffer,count==0
Consumer gets replaced by producer before it goes to sleep
Produces something, count++, sends wakeup to consumer
Consumer not asleep, ignores wakeup, thinks count= = 0, goes to sleep
Producer fills buffer, goes to sleep
P and C sleep forever
So the problem is lost wake-up calls

35. Quick Solution Add wakeup waiting bit
When wakeup is sent to process that is still wakeup, that bit is set
When the process tries to sleep, it the wakeup bit is on, it will be turned off – process still wakeup
Wakeup waiting bit is piggy bank for storing wakeup signals

36. Quick Solution – Pseudo code
if (count==0) {
if (w_bit == 0)
Sleep();
else
w_bit=0; }

37. Semaphores Semaphore is an integer variable
Used to sleeping processes/wakeups
Two operations, down and up
Down checks semaphore. If not zero, decrements semaphore. If zero, process goes to sleep
Up increments semaphore. If more then one process asleep, one is chosen randomly and enters critical region (first does a down)
ATOMIC IMPLEMENTATION-interrupts disabled

38. Producer Consumer with Semaphores
Use of UP and DOWN semaphores as system call
OS briefly disable all interrupts while it is testing the semaphores, updating it and putting process to sleep
Takes few CPU time – no harm on disabling interrupt
For multiple CPU peterson’s algorithm, TSL or XCHG instruction can be used
No long busy waiting as semaphores execution is very brief

39. Producer Consumer with Three Semaphores
3 semaphores: full, empty and mutex
Full counts full slots (initially 0)
Empty counts empty slots (initially N)
Mutex protects variable which contains the items produced and consumed i.e make sure that producer and consumer do not access the buffer at same time
Semaphore initialized to 1, used by two or more process to ensure CR is called binary semaphore

40. Producer Consumer with semaphores

41. Producer Consumer with semaphores Cont

42. Producer Consumer – Way of using Semaphore
Used in two different way
Full and empty used to ensure synchronization. They ensure certain event do or don’t occur.
Next mutex ensures critical section. Guarantee only one process at a time will be reading and writing the buffer with associated value

43. Dining Philosophers Problem
. Lunch time in the Philosophy Department.

44. Dining Philosophers Problem -- NonSolution
take_fork until next fork available
But fails if all five philosopher take left (or right for) simulatniously
Leads deadlock
Non Solution 2
Take left fork, checks right is available puts down the left one, waits for some time and repeat whole process
But fails if all philosophers starts the algorithm at same time checks next fork put down and again start at same time
Leads Starvation

45. Dining Philosophers Problem – NonSolution
A nonsolution to the dining philosophers problem.

46. Dining Philosophers Problem - Solution
Following to Call think using binary semaphore
Before acquire fork  down on mutex
After replacing fork  up on mutex
Theoretical view point solution is adequate
Practically – only one philosopher can be eating. With five fork we should be able to allow two philosopher eating
NOT maximum utilization of resources

47. Dining Philosophers Problem - Solution
Deadlock free and maximum parallelism for an arbitrary philosopher
Uses array, state of whether a philosopher is eating, thinking or hungry(trying to acquire fork)
A philosopher many only move eating state if neither neighbor is eating
Philosopher i’s neighbors are defines by left and right
If i=2 left is 1 and right is 3
LEFT = (i+N-1)%N
RIGHT = (i+1)%N
Array of semaphore – one per philosopher, so hungry philosopher can block if the needed forks are busy

48. Dining Philosophers Problem
. . .
A solution to the dining philosophers problem. N=5.

49. Dining Philosophers Problem
. . .
. . .
. A solution to the dining philosophers problem.

50. Dining Philosophers Problem
. . .
A solution to the dining philosophers problem.

51. Mutex Simplified version of Semaphore
Good for managing Mutual Exclusion
Easy and efficient to implement
Is in two states
Locked
Unlocked
One bit is enough, but in practice int is used
0 means unlocked other value locked
Two procedure can be used with mutex
mutex_lock
mutex_unlock

52. Mutexes
User space code for mutex lock and unlock

53. More Mutex
Enter region code for TSL results in busy waiting (process keeps testing lock)
Clock runs out, process is bumped from CPU
No clock for threads => spinning thread could wait forever =>need to get spinner out of there
Use thread_yield to give up the CPU to another thread.
Thread yield is fast (in user space).
No kernel calls needed for mutex_lock or mutex_unlock.

54. Monitors
Easy to make a mess of things using mutexes and condition variables. Little errors cause disasters.
Producer consumer with semaphores- interchange two downs in producer code causes deadlock
Monitor is a language construct which enforces mutual exclusion and blocking mechanism
C does not have monitor

55. Monitors
Monitor consists of {procedures, data structures, and variables} grouped together in a “module”
A process can call procedures inside the monitor, but cannot directly access the stuff inside the monitor
C does not have monitors

56. Monitor-a picture

57. Onwards
In a monitor it is the job of the compiler, not the programmer to enforce mutual exclusion.
Only one process at a time can be in the monitor
When a process calls a monitor, the first thing done is to check if another process is in the monitor. If so, calling process is suspended.
Need to enforce blocking as well –
use condition variables
Use wait , signal ops on cv’s

58. Producer Consumer Monitor

59. Monitors:Good vs Bad
The good-No messy direct programmer control of semaphores
The bad- You need a language which supports monitors (Java).
OS’s are written in C

60. Semaphores:Good vs Bad
The good-Easy to implement
The bad- Easy to mess up

61. Reality Monitors and semaphores only work for shared memory
Don’t work for multiple CPU’s which have their own private memory, e.g. workstations on an Ethernet

62. Message Passing Information exchange between machines Two primitives
Send(destination, &message)
Receive(source,&message)
Lots of design issues
Message loss
acknowledgements, time outs deal with loss
Authentication-how does a process know the identity of the sender? For sure, that is

63. Producer Consumer Using Message Passing
Consumer sends N empty messages to producer
Producer fills message with data and sends to consumer
If the producer works faster the consumer, all the message end up with full, the producer will be blocked, waiting empty message to come
If consumer works faster reverse happen

64. Producer-Consumer Problem with Message Passing (1)
. . . .

65. Producer-Consumer Problem with Message Passing (2)
. . .

66. Message Passing Approaches
Have unique ID for address of recipient process
Mailbox
In producer consumer, have one for the producer and one for the consumer
No buffering-sending process blocks until the receive happens. Receiver blocks until send occurs (Rendezvous)
MPI (Message-Passing Interface)