2/27/24

Operating Systems
Inter-Process Communications
Dr. Youssef Iraqi
College of Computing

Email: Youssef.Iraqi@um6p.ma

Operating Systems 1

Interprocess Communication

• Why interprocess communication (IPC)?

– processes frequently need to communicate with each other
•ex: in a shell pipe, output of process A must be passed (as an input) to
process B

• Processes communicate by sharing common storage

– shared main-memory locations
– shared buffers
– shared files

• IPC causes significant problems that need to be

addressed by OS because of sharing storage

Operating Systems 2

1
 2/27/24

Interprocess Communication

Example: Print Spooler

– spooler directory
•holds file names to be printed
•structured as a queue
– shared variables
•out - points to next file to be printed
•in - points to next free slot in directory
– printer daemon
•process - periodically checks to see if there are files to be
printed
–if yes, it prints them and updates variable out

Operating Systems 3

Interprocess Communication
Race Conditions

Two processes want to access a shared memory at the same time

Operating Systems 4

2
 2/27/24

Interprocess Communication
Race Conditions

Operating Systems 5

Interprocess Communication
Race Conditions

Operating Systems 6

3
 2/27/24

Race Conditions
• Race condition may occur
– two or more processes are reading/writing some shared
data and final result depends on who runs precisely when

• How to avoid race conditions?

– Need for mutual exclusion
•way of making sure that if one process using shared storage,
other processes will be excluded from doing same
– only necessary for sections concerned with shared
storage called critical sections or critical regions

Operating Systems 7

Critical Regions

4 conditions to provide efficient mutual exclusion

1. No two processes simultaneously in critical region

2. No assumptions made about speeds or numbers of CPUs

3. No process running outside its critical region may block

another process

4. No process must wait forever to enter its critical region

Operating Systems 8

4
 2/27/24

Critical Regions

Mutual exclusion using critical regions

Operating Systems 9

Mutual Exclusion
Approaches for achieving mutual exclusion
– used to solve race conditions
– some do not completely eliminate race conditions
1. Mutual Exclusion with Busy Waiting Methods
•Disabling Interrupts
•Lock variables
•Strict Alternation
•Peterson’s Solution
•Test & Set Lock
2. Sleep and Wakeup
3. Semaphores
4. Message Passing

Operating Systems 10

10

5
 2/27/24

Mutual Exclusion with Busy Waiting

Technique 1: Disabling Interrupts
– disable all types of interruptions upon entering a
critical region (CR)
•enable interruptions after exiting critical region
– unattractive method
•unwise to allow user to disable all interruptions
•what happens if user forgets to enable interruptions after
exiting CR?
– will not work in multi-CPU system
•disabling interrupts affect only CPU that executed disable
instruction
– sometimes useful within kernel
Operating Systems 11

11

Mutual Exclusion with Busy Waiting

Technique 2: Lock Variables
– use a single shared ‘lock’ variable
– when process wants to enter its CR, it first tests lock (which is
initially = 0)
– if lock = 0, process enters CR and sets lock to 1
– if lock = 1, process waits (keeps testing lock) until lock = 0
– technique has a flaw - rare situation but may happen
•if lock = 0, process A decides to enter CR but gets suspended before it
sets lock to 1
•process B may enter (since lock is 0)
•then process A wakes up and enter (lock is still 0)
•two processes in CR!

Operating Systems 12

12

6
 2/27/24

Mutual Exclusion with Busy Waiting

Technique 3: Strict Alternation

(a) Process 0. (b) Process 1.

Proposed solution to critical region problem
Strict alternation

Operating Systems 13

13

Mutual Exclusion with Busy Waiting

Technique 3: Strict Alternation
– continuously test a variable to see if your turn has
come
– not a good solution
•what happens if process 0 needs to enter CR frequently but
not process 1?
•violate condition- process 0 may be blocked by process not
in CR

Operating Systems 14

14

7
 2/27/24

Mutual Exclusion with Busy Waiting

Technique 4: Peterson’s Solution

– modified strict alternation - eliminates drawbacks

•process not in CR cannot block another process
– when process wants to enter CR, it first calls enter-
region()
•passes its process number as an argument
•if it is not allowed to enter, it will not return from enter-
region()
– before process leaves CR, it calls leave-region()

Operating Systems 15

15

Mutual Exclusion with Busy Waiting

Peterson's solution for achieving mutual exclusion

Operating Systems 16

16

8
 2/27/24

Mutual Exclusion with Busy Waiting

Technique 5: Test and Set Lock (TSL)

– hardware-based solution
– uses a special instruction Test-and-Set-Lock
•reads contents of memory word into register
•then stores a nonzero value at that memory location

– since interrupts only occur at the end of an instruction cycle,

TSL is ‘atomic’ and cannot be interrupted
– TSL locks memory bus
•other CPUs can’t access that location until operation is complete

Operating Systems 17

17

Mutual Exclusion with Busy Waiting

Entering and leaving a critical region using the

TSL instruction
Operating Systems 18

18

9
 2/27/24

Mutual Exclusion with Busy Waiting

Peterson’s solution and TSL are correct
– But both require busy waiting
•when process wants to enter CR, checks if allowed to enter
•if not, process executes loop waiting until it is

• not only is busy waiting wasteful of CPU time, it also

causes a priority inversion problem
– low priority process L is in CR
– high priority process H is busy waiting
– But since L is never scheduled while H is running, L never
gets the chance to leave its critical region, so H loops forever.

Operating Systems 19

19

Sleep and Wakeup

• Uses primitives that block instead of busy waiting
– block - meaning process goes to blocked state
– busy waiting - process is in ready or running states
• SLEEP
– system call that causes caller to block
– process suspended until another process wakes it up
• WAKEUP
– system call that wakes up or unblocks a process
• Simple implementation of sleep/wakeup still
produces race conditions

Operating Systems 20

20

10
 2/27/24

Producer-consumer problem
(bounded buffer)
• Two processes share a fixed-size buffer
– producer puts information into buffer
– consumer takes information out of the buffer

Operating Systems 21

21

Producer-consumer problem
(bounded buffer)
• What happens when producer wants to put an item
in buffer but buffer is full?
– producer goes to sleep
– awakened by consumer when consumer removed items

• What happens when consumer wants to remove an

item but buffer is empty?
– consumer goes to sleep
– awakened by producer when producer has added items

Operating Systems 22

22

11
 2/27/24

Sleep and Wakeup

Producer-
consumer
problem with
fatal race
condition

Operating Systems 23

23

Sleep and Wakeup

• Race condition occurs when:
– buffer is empty. Consumer runs and reads count = 0
– scheduler suspends consumer and runs producer
– producer puts item in buffer and increments count to 1
– since count = 1, producer sends WAKEUP to consumer
•consumer is not asleep, so WAKEUP is lost
– scheduler suspends producer and runs consumer
– consumer tests previously read count
•count = 0 for consumer, so consumer sleeps
– scheduler resumes producer
•producer will eventually fill buffer and sleeps
– now both producer and consumer sleep for ever!
• Better solution - Semaphores

Operating Systems 24

24

12
 2/27/24

Semaphores
• Dijkstra (65) recognized problem with previous
example
– WAKEUP is lost because consumer is awake
• use an integer value called semaphore
– count number of wakeups saved for future use
– can have a value of 0 --- no wakeups saved
– can have a positive value --- number of wakeups pending
• two operations: DOWN and UP (P and V originally)
– both are atomic- indivisible operations
– DOWN: if semaphore > 0 then decrement semaphore
else process sleeps; decrement semaphore (when awakened)
– UP: increment semaphore
if any process sleeping then wakeup one process at random

Operating Systems 25

25

Producer-consumer using Sephamores

• uses 3 semaphores
– Full counting number of slots that are full (0 initially)
– empty counting number of empty slots (N initially)
– mutex ensure mutual exclusion for access of buffer
(1 initially)
• mutex is binary semaphore
– either 0 or 1
– guarantee only one process can enter CR at a given time
– down (mutex) before entering CR
if mutex = 1 then set mutex = 0 and enter
else block; set mutex = 0 when awakened and enter
– up (mutex) when leaving CR
set mutex = 1
if process blocked then unblock it

Operating Systems 26

26

13
 2/27/24

Semaphores

producer-consumer
using semaphores

Operating Systems 27

27

Semaphores
• in solution to producer-consumer problem,
semaphores were used for two distinct purposes
– mutual exclusion
– synchronization
• mutual exclusion (ex: mutex)
– guarantees that only one process at a time will be reading or
writing the buffer and associated variables
• synchronization (ex: empty and full)
– guarantees certain event sequences do or do not occur
– producer stops running when buffer is full
– consumer stops running when buffer is empty

Operating Systems 28

28

14
 2/27/24

Mutexes

Operating Systems 29

29

Monitors

Monitor: a high-level synchronization primitive

– A collection of procedures, variables, and data structures

– processes may call the procedures in a monitor
– only one process can be active in a monitor at any instant.

Operating Systems 30

30

15
 2/27/24

Monitors

Operating Systems 31

31

Message Passing
• semaphores were designed for mutual exclusion and
synchronization in
– single CPU systems
– multi CPU systems with shared memory

• in distributed systems
– multiple CPUs each with private memory
– IPC does not use shared storage
– use of message passing for IPC

• two message-passing primitives (systems calls)

– send (destination, &message)
– receive (source, &message)
•if no message available, receiver could block until one arrives
Operating Systems 32

32

16
 2/27/24

Message Passing
• Design issues:

– Messages can be lost.

– Detecting duplicates
– Naming processes
– Authentication
– Performance

Operating Systems 33

33

Producer-consumer using Message Passing

• no shared memory
• message sent but not yet received is buffered by OS
• consumer starts by sending N empty messages
• when producer has an item to give
– it takes an empty message and sends back a full one
• when consumer receives a full message
– it processes it and sends back an empty message
• if producer works faster than consumer
– producer may block (on receive) waiting for empty message
• if consumer works faster than producer
– consumer may block waiting for full message
Operating Systems 34

34

17
 2/27/24

Message Passing

The producer-
consumer
problem with
N messages

Operating Systems 35

35

Message Passing Implementation

• Asynchronous message-passing
– send does not block, receive blocks
– need for buffering mechanism - called mailbox
•mailbox is a place to buffer certain number of messages
• Synchronous message-passing
– both send and receive block until there is a rendezvous
– no need for buffering
•when rendezvous occurs, send sends information to receive
• IPC between user processes in Unix can be via pipes
– pipe is effectively a mailbox
– only difference, pipe does not preserve message boundaries
•ex: if process A sends 10 messages of 100 bytes to pipe and process
B reads 1000 bytes from pipe, A gets all 10 messages

Operating Systems 36

36

18
 2/27/24

The Readers and Writers Problem

• Ex: access to a database by many processes
– readers: many can read at same time
– writers: if process is changing (writing) database, no other
processes should have access to it

• Solution using semaphores

– one binary semaphore to allow writer to have exclusive access
to database
– as long as there is one reader, writer should not access
database
•use counter (shared) variable to count number of readers
•need another semaphore to get exclusive access to the shared counter
variable

Operating Systems 37

37

The Readers and

Writers Problem

solution to readers
and writers problem

Assumes readers have priority over

writers!

Operating Systems 38

38

19