Operating Systems Theory – Using Minimum Number of Semaphores

algorithmsoperating systemsresourcessignalstheory

This situation is prone to deadlock of processes in an operating system and I'd like to solve it with the minimum of semaphores. Basically there are three cooperating processes that all read data from the same input device. Each process, when it gets the input device, must read two consecutive data. I want to use mutual exclusion to do this. Semaphores should be used to synchronize:

P1:                     P2:                     P3:
input(a1,a2)            input (b1,b2)           input(c1,c2)
Y=a1+c1                 W=b2+c2                 Z=a2+b1
Print (X)               X=Z-Y+W

The declaration and initialization that I think would work here are:

semaphore s=1

sa1 = 0, sa2 = 0, sb1 = 0, sb2 = 0, sc1 = 0, sc2 = 0

I'm sure that any kernel programmers that happen on this can knock this out in a minute or 2.

Diagram of cooperating Processes and one input device:

enter image description here

It seems like P1 and P2 would start something like:

wait(s)

input (a1/b1, a2/b2)

signal(s)

Best Answer

Your process description seems to suggest that P1 needs data read by P3 (c1), P2 needs data read by P3 (c2), and P3 needs data read by P1 and P2 (a2 and b1).

So, is this what needs to happen (where * can occur anytime after 2):

  1. P1 <- read a1
  2. P3 <- read c1
  3. P3 <- read c2
  4. P2 <- read b1 and b2 *. P1 <- read a2

Or do P1, P2, and P3 use a cache of the last value read in the other process?

If the latter, you just need one mutual exclusion semaphore to control access to the device. If the former, you can have a fourth process that handles reading all the data and synchronize on when a valid set is available for all the use and when the data set has been read by all parties.

The fourth process doesn't have to know ahead of time what the data to be read is, it can simply implement a message queue where P1, P2, and P3 send it the parameters for data to be read. It then incrementes a counting semaphore each time it completes reads from each process. After sending their read message, everyone waits until the "data ready" semaphore reaches 3, then knows a valid set of data is available. After doing a read, they in turn increment a "data read" semaphore and wait for it to reach 3. When it does, they then wait on the "data ready" semaphore to go to 0 (the fourth process handles this after everyone has signaled their read, setting the "data ready" semaphore back to 0 then the "read data" semaphore back to 0. and the whole process repeats itself. Note, you'd never have a case where a process could miss the transition back to zero (deadlock) since each process needs to signal that their read is complete before the wait for "data ready" to go to zero by the time the third process gets around to doing it's read.

So, bottom line, you should be able to implement this with either 1 semaphore or 2 depending on what your requirements are for a concurrent set of data.

EDIT - Reviewing this, the "data ready" semaphore doesn't need to be a counting one since the thread with sole ownership of the input device can simply keep an internal count and just signal once when a complete data set is ready.

Related Topic