Shared Data Problem: Shared Data Problem can arise in a system when another higher priority task finishes

an operation and modifies the data. Shared Data Problem causes inconsistencies in the data used by a particular task due to another ISR occurs at the wrong time. Data is often shared because if the ISRs do all the work, they would take a lot of time. Example to explain the Shared Data Problem: Consider that an ISR is being executed. Let there be a variable of some data type which is being used. Let us assume that this variable is being used in a while loop. Now, before this while loop is completely implemented, ANOTHER INTERRUPT OCCURS!!! It is necessary to understand that this second interrupt has a higher priority than the previous one. Because of this, the value of the variable may differ from the one expected if the earlier operation had been completed. It means that the value of the variable may be modified. Some of the options to avoid Shared Data Problems can be1) Disabling the Interrupts 2) Semaphores

1) Disabling the Interrupts: Here, the Interrupts are disabled before a critical section starts executing and are again enabled when the critical section ends. An interrupt, even of higher priority than the present one gets disabled. The problem of using this option is that it increases the Interrupt Latency and a deadline may be missed for an interrupt service. Therefore, this option i.e. disabling of the interrupts is considered drastic and is avoided by Software Designers.

2) Semaphores: A Semaphore is a notifying variable used when executing the critical section codes. This notifying variable helps to eliminate the shared data problem. The OS does the job of taking and returning the Semaphore from a particular task. Let us examine the example given below. A process A, when executing a critical section, notifies the OS to take the Semaphore i.e. take notice of it. Further, The OS returns the Semaphore as taken i.e. accepted. Now, the process A executes the codes of the critical section. The OS, having been notified earlier, does not return the Semaphore to another process B. for better understanding, observe the figure shown below:

In the above Diagram,

The Task A Requesting for taking semaphore with the OS The OS acknowledges and asks task A to take the semaphore During that time Task B is Blocked (which also uses the same Semaphore) Task A Releases the Semaphore, Event to the OS Task B starts running by taking the semaphore (The Semaphore Flag is used to indicate the status of the activity).

Similarly, use of multiple Semaphores is shown in the below diagram:

In the above diagram: A. Two semaphores X and Y are used B. Task I, J and M share the semaphore X C. Task K and L Share the semaphore Y D. In the above diagram, the tasks J and M are waiting for taking the semaphore X as the semaphore is locked by the Task I E. Similarly, the other semaphore Y is been locked by Task L and hence Task K is waiting Semaphore provides a mechanism to let a task wait till another finishes.

RTOS examples: Currently the best known, most widely deployed, real-time operating systems are: 1) LynxOS 2) OSE 3) QNX

4) RTLinux

5)

VxWorks

6) Windows CE

1) LynxOS: The LynxOS RTOS is a real-time operating system from LynuxWorks (formerly "Lynx Real-Time Systems"). Sometimes known as the Lynx Operating System, LynxOS features full POSIX conformance and, more recently, Linux compatibility. LynxOS is mostly used in real-time embedded systems, in applications for avionics, aerospace, the military, industrial process control and telecommunications The LynxOS RTOS (real-time operating system) is the superior foundation for sophisticated real-time systems: y Full POSIX conformance in an embedded RTOS y Mission-critical RTOS performance and reliability y Advanced networking feature sets y Latest RTOS technologies for Internet communications What is POSIX? POSIX is the Portable Operating System Interface, the open operating interface standard accepted world-wide. It is produced by IEEE and recognized by ISO and ANSI. POSIX support assures code portability between systems and is increasingly mandated for commercial applications and government contracts.

Real-time determinism: All RTOS components within LynxOS are designed for absolute determinism (i.e.: hard real-time performance). This means that they absolutely must respond within a known period of time. This predictable response is ensured even in the presence of heavy I/O due to the kernel's unique threading model, enabling interrupt routines to be extremely short and fast.
y y y

Perform complex series of tasks within set periods of time Support multiple applications with multiple interrupting devices Take full advantage of today's powerful high-end microprocessor and advanced networking architecture.

2)

ENEA OSE:

Enea OSE is an RTOS optimized for distributed, fault-tolerant systems.

It is compact and robust, and powers embedded systems in wide-range of vertical markets from telecom to automotive to industrial automation and beyond. High performance and great scalability: One of the contributing factors why Enea OSE ensures high performance is the modular, layered architecture. Another factor is the direct, asynchronous, message-passing design. Together they achieve scalability(capability of a system to increase total throughput under an increased load when resources (typically hardware) are added.) from one single CPU to large, distributed, multi-CPU and multi core systems. Enea OSE is one of the most widely used RTOSes in the world. According to mobile analyst firm, VisionMobile, OSE has been deployed in over 1.75 billion mobile handsets, as of the end of June 2010.[1] Enea OSE is shipped in hundreds of millions of mobile phones each year and over half of the world's 3G base stations.

3) QNX: