IPC and Classical Synchronization Problems

1
IPC and Classical Synchronization Problems
2
How do processes communicate?

• IPC (Inter Process Communication)
• Mechanism to exchange data
• Why?
• Share information
• Computational speedup
• Modularity
• Convenience
• Why not use threads?
• Functionality, manufacturers,

3
IPC Message Passing

• OS provided mechanism
• Address space is NOT shared
• Process use 2 operations
• send(message)
• receive(message)
• Size of message
• Fixed simple implementation but difficult to use
• Variable commonly used

4
Naming

• Direct communication
• Explicitly name the end-point
• Link is between exactly two processes
• Between any two processes there is only one link
• Symmetric
• Name the endpoints
• Send(P, msg) and Receive(Q, msg)
• Asymmetric
• Receive does not name endpoint
• Send(P, msg) and Receive(id, msg)
• Hard coding required!

5
Naming

• Indirect communication Mailbox or ports
• Messages sent and removed from a mailbox
• Link can be between more than 2 processes
• More than 2 processes can share a link
• Who owns the mailbox?
• Process
• Different from shared memory
• Owner is the receiver
• Other processes can only send
• OS
• System calls to create, communicate and delete
  mailboxes
• Ownership of mailbox can be passed using system
  calls

6
IPC Shared Memory

• Memory is shared among processes
• Shared memory is part of a processs address
  space
• The part to be shared is decided by process and
  not OS
• Example POSIX

7
Comparing these schemes

• Message passing
• Easier to implement
• No conflicts to consider, good for small data
  transfers
• Example MPI
• Shared memory
• Faster for local transfers
• Cheriton84 to make message passing fast
• Distributed Shared Memory vs Message Passing
• Distributed computation?
• Multiprocessor architectures?

8
Synchronization Problems

• Producer-Consumer Problem
• Readers-Writers Problem
• Dining-Philosophers Problem
• Sleeping Barber Problem

9
Producer-Consumer Problem

• Unbounded buffer
• Producer process writes data to buffer
• Writes to In and moves rightwards
• Consumer process reads data from buffer
• Reads from Out and moves rightwards
• Should not try to consume if there is no data

Out
In
Need an infinite buffer
10
Producer-Consumer Problem

• Bounded buffer size N
• Producer process writes data to buffer
• Should not write more than N items
• Consumer process reads data from buffer
• Should not try to consume if there is no data

In
Out
11
Producer-Consumer Problem

• A number of applications
• Compilers output consumed by assembler
• Assemblers output consumed by loader
• Web server produces data consumed by clients web
  browser
• Example pipe ( ) in Unix
• gt cat file more
• gt prog sort what happens here?

12
Producer-Consumer Problem

• First attempt to solve

Shared int counter any_t
bufferN Init counter 0
Producer while (true) / produce an item
in nextProduced/ while (counter N)
/ do nothing / bufferin
nextProduced in (in 1) N
counter
Consumer while (true) while (counter
0) / do nothing / nextConsumed
bufferout out (out 1) N
counter-- / consume an item in
nextConsumed/
13
Producer-Consumer Problem
Shared Semaphores mutex, empty, full Init
mutex 1 / for mutual exclusion/
empty N / number empty bufs / full
0 / number full bufs /
Producer do . . . // produce an item
in nextp . . . P(empty) P(mutex)
. . . // add nextp to buffer . . .
V(mutex) V(full) while (true)
Consumer do P(full) P(mutex) . .
. // remove item to nextc . . .
V(mutex) V(empty) . . . //
consume item in nextc . . . while (true)
14
Readers-Writers Problem

• Courtois et al 1971
• Models access to a database
• Example airline reservation

15
Readers-Writers Problem

• Many processes share a database
• Some processes write to the database
• Only one writer can be active at a time
• Any number of readers can be active
  simultaneously
• This problem is non-preemptive
• Wait for process in critical section to exit
• First Readers-Writers Problem
• Readers get higher priority, and do not wait for
  a writer
• Second Readers-Writers Problem
• Writers get higher priority over Readers waiting
  to read
• Courtois et al.

16
First Readers-Writers
Shared variables Semaphore mutex, wrl
integer rcount Init mutex
1, wrl 1, rcount 0 Writer do
P(wrl) . . . /writing is performed/
. . . V(wrl) while(TRUE)
Reader do P(mutex) rcount if
(rcount 1) P(wrl) V(mutex) .
. . /reading is performed/ . . .
P(mutex) rcount-- if (rcount 0)
V(wrl) V(mutex) while(TRUE)
17
Readers-Writers Notes

• If there is a writer
• First reader blocks on wrl
• Other readers block on mutex
• Once a writer exists, all readers get to go
  through
• Which reader gets in first?
• The last reader to exit signals a writer
• If no writer, then readers can continue
• If readers and writers waiting on wrl, and writer
  exits
• Who gets to go in first?
• Why doesnt a writer need to use mutex?

18
Dining Philosophers Problem

• Dijkstra
• Philosophers eat/think
• Eating needs two forks
• Pick one fork at a time
• How to avoid deadlock?

Example multiple processes competing for limited
resources
19
A non-solution
define N 5 Philosopher i (0, 1, ..
4) do think() take_fork(i)
take_fork((i1)N) eat() / yummy /
put_fork(i) put_fork((i1)N) while
(true)
20
Will this work?
Shared semaphore fork5 Init forki 1 for
all i0 .. 4 Philosopher i do
P(forki) P(forki1) / eat /
V(forki) V(forki1) / think /
while(true)
21
Dining Philosophers Solutions

• Allow only 4 philosophers to sit simultaneously
• Asymmetric solution
• Odd philosopher picks left fork followed by right
• Even philosopher does vice versa
• Pass a token
• Allow philosopher to pick fork only if both
  available

22
One possible solution
Shared int state5, semaphore s5, semaphore
mutex Init mutex 1 si 0 for all i0 .. 4
take_fork(i) P(mutex) statei
hungry test(i) V(mutex)
P(si) put_fork(i) P(mutex)
statei thinking test((i1)N)
test((i-1N)N) V(mutex)
Philosopher i do take_fork(i) / eat
/ put_fork(i) / think / while(true)
test(i) if(statei hungry
state(i1)N ! eating state(i-1N)N
! eating) statei eating V(si)