Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

And there are situations were the task may block for a very long time, even indefinitely, on a mutual exclusion semahoresemaphore.  Consider the following scenario:  A driver that reads data could have a sequence like this:

  1. Get exclusive access to the driver by taking a semaphore
  2. Wait on a signaling semaphore for data (might be a long time)
  3. Release the mutual exclusion semaphore.

Now suppose there are two applications, Task A and Task B, that open the driver and try to read from it. The first, Task A, will get the mutual exclusion semaphore at (1) and then will hang waiting for data at (2).  It may have to wait for a very long time to receive data.  When re-entered by the second, Task B, it will hang at (1) also for very long time.  Task B is effectively queued and cannot event begin its wait on the signaling semphore until Task B A receives its data and releases the mutual exclusion semaphore. This is normal behavior and exactly, how this kind of driver is supposed to work.

But now suppose that Task B receives a signal interrupt or a cancellation event while waiting on the mutual exclusion semaphore. It MUST terminate the wait and return -EINTR or -ECANCEL immediately.  Task A may never receive data and if that action is not taken, the signal interrup or cancellation event is lost and the functionality has failed.

...