Chapter 2.3 : Interprocess Communication

1
Chapter 2.3 Interprocess Communication

• Process concept ?
• Process scheduling ?
• Interprocess communication
• Deadlocks
• Threads

2
Producer - Consumer Problem
Producer Process
Consumer Process
BUFFER

• Buffer is shared (ie., it is a shared variable)

3
Progress in time..
Producer
3 instead of 2!
c1

• Both processes are started at the same time and
  consumer uses some old value initially

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
• lock1
• put in buffer
• lock0
• Consumer
• If lock 1 loop until lock 0
• lock1
• get from buffer
• lock0
• Consume
• Note initially lock 0

13
Dekkers 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 wantptrue 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 wantqfalse 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 wantptrue 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 Ps turn, turn 2 Qs turn
• If a process is blocked, the other process can
  still go
• Dekkers 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 xr and r1
  
• x is a local variable
• r is a global register set to 0 initially
• repeat (testset(x)) until x 0
• lt critical section gt
• 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
• lt critical section gt
• exchange(r, x)
• Note r 0 and x 1 when the process is in 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 gt 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
Produce Wait(mutex) Put in buffer Signal(mutex)
Wait(mutex) Get from buffer Signal(mutex) Consume
CS

• Initially semaphore mutex is 1

25
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

• Semaphore b 0, c 0

27
Dining Philosophers
Figure is from Modern OS by Tanenbaum

• 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

28
Dining Philosophers Solution First Attempt

• Program diningphilosophers
• Var i integer
• fork array0..4 of semaphore
• Procedure philosopher (i integer)
• Begin
• repeat
• think
• wait(forki) ( get left fork )
• wait(fork(i1) mod 5 ( get right fork )
• eat
• signal(forki) ( return left fork )
• signal(fork(i1) mod 5 ( return right fork
  )
• until false
• End
• Begin ( main )
• for i 0 to 4 do forki 1 ( initially all
  forks are available )
• cobegin
• philosopher(0) philosopher(1) philosopher(2)
  philosopher(3) philosopher(4)

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 array0..4 of semaphore
• i integer
• table semaphore ( seating limit )
• Procedure philosopher (i integer)
• Begin
• repeat
• think
• wait(table)
• wait(forki) ( get left fork )
• wait(fork(i1) mod 5 ( get right fork )
• eat
• signal(forki) ( return left fork )
• signal(fork(i1) mod 5 ( return right fork
  )
• signal(table)
• until false
• End
• Begin ( main )
• for i 0 to 4 do forki 1 table 4

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 (i0 iltN i) send(producer,m)
• while (TRUE)
• receive(producer,m)
• extract_item(m,item)
• send(producer,m)
• consume_item(item)