Elimination of Shared Data Problem or Problems with Semaphores

Elimination of Shared Data Problems or Problems with Semaphores

The use of semaphores does not eliminate the shared data problem completely.

So there are some problems when using semaphores

• Sharing of two semaphores leads to deadlocks
• Suppose that the locked semaphore is not released? There should be some timeout interval in which after the timeout the Watch Dog Timer will reset the processor thereby the error is handled by a function
• A semaphore is not taken as another task uses a shared variable
• A wrong semaphore is taken by a task
• There may be priority inversion problem

Deadlocks

Suppose if there are two semaphores S1 and S2, and there are two tasks T1 and T2. The locking will be in the following cycle

T1-> S1 -> S2-> T1

T2 -> S2 -> S1 -> T2

The above two scenarios, both the Tasks T1 and T2 needs to take the semaphores S1 and S2. Both the tasks wont release the semaphores until it completes the execution

Task T1 locks S1 and waiting for S2 which is been locked by T2. similarly, the task T2 also waits for s1 which is being locked by T1. This problem is called as Deadlock

Priority Inversion Problem

The real trouble arises at run-time, when a medium-priority task preempts a lower-priority task using a shared resource on which the higher-priority task is pending. If the higher-priority task is otherwise ready to run, but a medium-priority task is currently running instead, a priority inversion is said to occur.

This dangerous sequence of events is illustrated in Figure 1. Low-priority Task L and high-priority Task H share a resource. Shortly after Task L takes the resource, Task H becomes ready to run. However, Task H must wait for Task L to finish with the resource, so it pends. Before Task L finishes with the resource, Task M becomes ready to run, preempting Task L. While Task M (and perhaps additional intermediate-priority tasks) runs, Task H, the highest-priority task in the system, remains in a pending state.
Many priority inversions are innocuous or, at most, briefly delay a task that should run right away. But from time to time a system-critical priority inversion takes place. Such an event occurred on the Mars Pathfinder mission in July 1997. The Pathfinder mission is best known for the little rover that took high-resolution color pictures of the Martian surface and relayed them back to Earth.
The problem was not in the landing software, but in the mission software run on the Martian surface. In the spacecraft, various devices communicated over a MIL-STD-1553 data bus. Activity on this bus was managed by a pair of high-priority tasks. One of the bus manager tasks communicated through a pipe with a low-priority meteorological science task.
On Earth, the software mostly ran without incident. On Mars, however, a problem developed that was serious enough to trigger a series of software resets during the mission. The sequence of events leading to each reset began when the low-priority science task was preempted by a couple of medium-priority tasks while it held a mutex related to the pipe. While the low-priority task was preempted, the high-priority bus distribution manager tried to send more data to it over the same pipe. Because the mutex was still held by the science task, the bus distribution manager was made to wait. Shortly thereafter, the other bus scheduler became active. It noticed that the distribution manager hadn't completed its work for that bus cycle and forced a system reset.
This problem was not caused by a mistake in the operating system, such as an incorrectly implemented semaphore, or in the application. Instead, the software exhibited behavior that is a known "feature" of semaphores and intertask communication. In fact, the RTOS used on Pathfinder provided an optional priority-inversion workaround; the scientists at JPL simply hadn't been aware of that option. Fortunately, they were able to recreate the problem on Earth, remotely enable the workaround, and complete the mission successfully.