3.1.2.

Potential Interprocess Communication

Problems
Interprocess communication (IPC) requires the use of resources, such as memory, which are
shared between processes or threads. If special care is not taken to correctly coordinate or
synchronize access to shared resources, a number of problems can potentially arise.

3.1.2.1. Starvation
A starvation condition can occur when multiple processes or threads compete for access to a
shared resource. One process may monopolise the resource while others are denied access.

3.1.2.2. Deadlock
A deadlock condition can occur when two processes need multiple shared resources at the
same time in order to continue.

These two pirates are in deadlock because neither is willing to give-up what the other pirate
needs.

A Computer Example of Deadlock:

Thread A is waiting to receive data from thread B. Thread B is waiting to receive

data from thread A. The two threads are in deadlock because they are both waiting
for the other and not continuing to execute.

3.1.2.3. Data Inconsistency

When shared resources are modified at the same time by multiple resources, data errors or
inconsistencies may occur. Sections of a program that might cause these problems are called
critical sections. Failure to coordinate access to a critical section is called a race condition
because success or failure depends on the ability of one process to exit the critical section
before another process enters the critical section. It is often the case that two processes are
seldom in the critical section at the same time; but when there is overlap in accessing the
critical section, the result is a disaster.

3.1.2.4. Shared Buffer Problem

An example of data inconsistency that can occur because of a race condition is what can
happen with a shared bank account. Dear Old Dad adds money to an account and Poor
Student withdraws from the account. When either accesses the account, they execute a critical
section consisting of three steps.

1. Read account balance

2. Update the balance
3. Write the new balance to the account
One day, Dear Old Dad checks the balance and seeing that it is $100 decides to add $50 to the
account. Unfortunately, access to the account is not locked, so just then Poor Students
withdraws $20 from the account and the new balance is recorded as $80. After adding the $50,
Dear Old Dad records the balance as $150, rather than $130, as it should be.

The nature of the problem is more clear when we examine the assembly language code for
such an operation:

The root of the problem stems from a context switch occurring in the middle of the execution
of the critical section.