Skip to main content

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.

Comments

Popular posts from this blog

Implementing a new system call in Kernel version 2.6.32

A system call is used by application or user programs to request service from the operating systems. Since the user programs does not have direct access to the kernel whereas the OS has the direct access. OS can access the hardware through system calls only. The following files has to be modified for implementing a system call /usr/src/linux-2.6.32.5/arch/x86/kernel/syscall_table_32.S /usr/src/linux-2.6.32.5/arch/x86/include/asm/unistd_32.h /usr/src/linux-2.6.32.5/include/linux/syscalls.h /usr/src/linux-2.6.32.5/Makefile New set of files to be created Create a new directory newcall/ inside the path “ /usr/src/linux-2.6.32.5/ ” Create new files Makefile, newcall.c and put them in the /usr/src/linux-2.6.32.5/newcall/ folder Create new user files (in any folder of Linux) to test the system call testnewcall.c, testnewcall.h (created in /home/pradeepkumar ) syscall_table_32.S Find the file /usr/src/linux-2.6.32.5/arch/x86/kernel/syscall_tab

How to Access MOODLE in Intranet and Internet

When Moodle is accessed either in Intranet or internet, there will not be any issue. But occasions when the MOODLE Site has to be accessed both in the intranet and in the Internet, here is a simple trick Server Used: IBM Blade Servers Operating system: Windows Server 2008 Moodle Version: 2.4 WAMP Server is used. Number of Users: 3000 (Students) + 200 (Faculty) Open the config.php from ~/moodle/config.php include these lines $CFG->wwwroot = 'http://'.$server_id.'/vitcc'; $CFG->dataroot  = 'C:\\wamp\\moodledata'; before the following line $CFG->directorypermissions = 07xx; Restart the WAMP Server and you can Check MOODLE Site both in Internet and Intranet. The above Image tells the intranet Link and the internet link can be opened outside the campus network

Electrical Machine Design (equations)

Factors DC Machine Transformers Induction Machines Synchronous Machines Output Equation P a =C o D 2 Ln, where Pa=P/h for generators, Pa=P for motors For Single Phase Q=2.22 f B m A i K w A w d 10 -3 For Three Phase Q=3.33 f B m A i K w A w d 10 -3 Q=C o D 2 L n s KVA Input Q= HP * 0.746 / Cos f * h Q=C o D 2 L n s KVA Input Q= HP * 0.746 / Cos f * h For Turbo alternators Q=1.11B av ac K ws V a 2 L 10 -3 /n s Output Coefficient C o =B av ac* 10 -3 where Bav-magnetic loading and ac - electric loading DNA C o =11 K ws B av ac 10 -3 C o =11 K ws B av ac 10 -3 Choice of Magnetic Loading Flux Density in Teeth Frequency of Flux Reversals Size of machine DNA Magnetizing current, Flux Density, Iron loss Iron loss, Stability, Voltage Rating, Parallel Operation, Transient ShortCircuit current