OSEK Powerpoint

OSEK Powerpoint File for download

Continue

Virtual Sockets and Remote Procedure Call (RPC)

Virtual Sockets

• Tasks or section of Tasks can communicate with another task or section of task
• The tasks may send or receive the stream of bytes or datagram to communicate with each other
• It is similar like IP Address / Port.
  
• In the above diagram, Task C in the Task Set is communicating with Task D in the Same Task Set
• Similarly, the Section I Portion of Task A is communicating with Section J of Task B.

Remote Procedure Call (RPC)

• When a Task1 at System 1 and Task2 at System 2, then Remote Procedure call is used.
• RPC Will be used only when both the systems are connected peer to peer but not in client server mode
  

Continue

Pipes (IPC)

• Pipes are similar like message queues
  
• A pipe can be opened or closed similar like a fopen() and fclose() of a C Program
  
• A Task can write through a scheduler to a pipe at the back pointer address (*pBACK)
  
• A Task can read through a scheduler to a pipe at the front pointer address (*pFRONT)
  

Continue

Mailboxes (IPC)

Mailboxes

• A Meassage mailbox is an IPC message Block that can be used only by a single destined Task


• The source is the task that sends the message pointer to a created mailbox.


• Example is the Mobile phone LCD Multiline display task in which the time and list of phone number displayed on a single display
• There are three forms of Mailboxes most of the RTOS supports
• 1. One Message per box
• 2. Multiple messages queuing up
• 3. Multiple messages with a priority value (According to the priority values, the insertion happens at the middle and reading or deleting happens at the front of the queue)
  

Continue

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.

Continue

Semaphores

In the above Diagram,

• The Task A Requesting for taking semaphore with the Kernel or Operating System
• The kernel acknowledge and ask task A to take the semaphore
• During that time Task B is Blocked (which also uses the same semphore)
• Task A Releases the semaphore, Event to the OS
• Task B starts running by taking the semaphore

Use of Multiple Semaphores

• Two semaphores X and Y are used
• Task I, J and M share the semaphore X
• Task K and L Share the semaphore Y
• In the above diagram, the tasks J and M are waiting for taking the semaphore X as the semaphore is locked by the Task J
• similarly, the other semaphore Y is been locked by Task L and hence Task K is waiting

Continue

Shared data Problems and its solutions

Assume that several ISRs or tasks share a variable. If there is a variable currently running under a task and there is an interrupt and some other task will be taking the control of that variable. Since the variable is already used by other task, so there comes a shared data problem.
The bugs encountered in the above process can be eliminated by means of following techniques

• use of volatile modifier - this declaration warns the compiler that certain variables can modify because the ISR does not consider the fact that the variable is also shared with a calling function
• reentrant function - part of a function that needs its complete execution before it can be interrupted. This part is called the critical section.
• put a shared variable in a circular queue - a function that requires the value of this variable always delete it from the queue front and another function which inserts the value of this variable,a lways does so at the queue back.
• Disabling the interrupts before a critical section starts executing and enable the interrupts on its completion. In this method, the high priority task or ISRs will be waiting because of the disabling of the interrupts
• Semaphores- which is a nice option for shared data problems and it is efficient also

Continue

Message Queues (IPC)

Message Queues

• Either one task or group of tasks can use the queue
• Usually queue is circular. elements are accessed by means of FIFO.
• Printer task is an example

Queue

• Initialization before using the function
• provision for multiple queues. each queue will be having an ID
• size of the queue is either user defined or predefined by the scheduler
• There may be a need for error handler, when a queue is full.

Continue

Signals

Signals

• Signal is a short message sent from a process for enabling inter process communication
• Signal is usually a one bit output comes from a process
• signal takes a shortest possible CPU time unlike Semaphores.
• Signals are useful for handling exceptions
• Whenever there is an error during a running of process, a signal is generated thereby the scheduler schedules a process to handle that error, in this way signals are used extensively for error and exception handling
  

Continue

Inter Process Communication (IPC)

Interprocess Communication (IPC)
A process (task or ISR) generates an input information by setting or resetting a flag or value or generates an output, which will be used by some other process.

Various techniques behind IPC are

• Signals
• Semaphores (Counting semaphore or binary semaphores)
• Message Queues, Mailboxes and Pipes
• Virtual Sockets
• Remote Procedure calls (RPC) for distributed Processes
  

Continue