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.

../_images/pirate_deadlock.png

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.

../_images/crit_section.png

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
../_images/shared_var.png

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:

../_images/asm_shared.png

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