Potocol (S & C)

Kernel typically makes these facilities available to application processes through Inter-Process Communication (IPC) mechanisms and System Calls.

While the Kernel's responsibilities include managing the system's resources (through communication between hardware and software components), key aspect necessary in resource management is the definition of an execution domain (address  space) and the Protection Mechanism used to mediate the accesses to the resources within a domain. Kernel provides Inter-Process Communication (IPC) for Synchronization & Communication between processes and a method to make requests to access these facilities and allow other programmes to run and use these resources.

Typically, the resources consist of:

•             Central Processing Unit, responsible for running or executing programmes. The Kernel takes responsibility for deciding at any time which of the many running programmes should be allocated to the processor(s).

•             Computer Memory, used to store both programme instructions and data. Typically, both need to be present in memory in order for a programme to execute. The Kernel is responsible for deciding which memory each process can use, and determining what to do when not enough is available.

•             Input/Output (I/O) Devices, such as keyboard, mouse, disk drives, USB devices, printers, displays, network adapters, etc. The Kernel allocates requests from applications to perform I/O to an appropriate and provides convenient methods for using the device.

Synchronization & Communication

Depending on how much functionality is required, Kernel introduces more or less of the Complexities of managing multiple tasks running conceptually in parallel.

Task Synchronization and Intertask Communications serve to enable information to be transmitted safely from one task / thread to another without danger of that information ever being damaged. The service also makes it possible for threads / tasks to coordinate and productively cooperate with one another.

As any code can potentially damage the data of another task, programmes must be carefully designed and tested, and access to shared data must be controlled by some Synchronization & Communication strategy, such as message queues, semaphores or a non-blocking synchronization scheme. It is because of these Complexities, that Organisations use Real-Time Operating System (RTOS), allowing the application programmers to concentrate on device functionality rather than Operating System services, at least for large systems; smaller systems often cannot afford the overhead associated with a generic real time system, due to limitations regarding memory size, performance, or battery life.

Without the help of these RTOS services, tasks might well communicate corrupted information or otherwise interfere with each other. For instance, as a case to study, a task might be preempted when it is in the middle of updating a table of data. If a second task that preempts it reads from that table, it will read a combination of some areas of newly-updated data plus some areas of data that have not yet been updated. [called "mish-mash."] These updated and old data areas together may be incorrect in combination, or may not even make sense. An example is a data table containing temperature measurements that begins with the contents "10 C." A task begins updating this table with the new value "99 F", writing into the table character-by-character. If that task is preempted in the middle of the update, a second task that preempts it could possibly read a value like "90 C" or "99 C." or "99 F", depending on precisely when the preemption took place. The partially updated values are clearly incorrect, and are caused by delicate timing coincidences that are very hard to debug or reproduce consistently. An RTOS's mechanisms for Synchronization & Communication between tasks are provided to avoid these kinds of errors. RTOSes provide mechanisms optimized for reliably passing a different kind of information from task to task.

 

Synchronization & Communication is also essential for tasks to share mutually exclusive resources (devices, buffers, etc) and/or allow multiple concurrent tasks to be executed (e.g. Task A needs a result from Task B, so Task A can only run till Task B produces it). It can take the form of an Event Object, a Semaphore (flag), or it can be in the form of a Message sent to another thread.

 

The most basic communication is via an Event. An Event is a way for a single thread to communicate with another thread. An interrupt service routine (ISR) can also send an event to a thread. Some RTOS can also send one (1) event to more than one thread. Event objects are used when task Synchronization is required without resource sharing. They allow one or more tasks to keep waiting for a specified event to occur. An event object can exist in either of two states: triggered and non-triggered. An event object in a triggered state indicates that a waiting task may resume. In contrast, if the event object is in a non-triggered state, a waiting task will need to stay suspended.

 

Semaphores are usually used to protect shared resources, for example if there is more than one thread that needs to read/write to the same memory (variable). This is done so that a variable does not Change through the actions of another thread while it is being addressed by the active thread. The principle is that you need to obtain a semaphore associated with a variable protected in this way before reading/writing to this memory. Once you have obtained the semaphore, no one else can read/write to this memory until you release the semaphore. This way you can ensure that only one thread at the time reads/writes to a memory location or variable. Sharing of resource among tasks can be a problem when the coordination is not done  well. For instance, if task A begins reading a set of data currently being updated by task B, task A might received corrupted data – mixture of new and existing data. To resolve this problem, RTOS Kernels provide a semaphore object and associated semaphore services to ensure the integrity of data.

A semaphore has an associated resource count and a wait queue. The resource count indicates availability of resource. The wait queue manages the tasks waiting for resources from the semaphore. A semaphore functions like a key that define whether a task has the access to the resource. A task gets an access to the resource when it acquires the semaphore. The resource count of a semaphore determines the number of times the semaphore can be acquired. When a task acquires the semaphore, its count decrement by one. Likewise, its count increment by one when a task releases the semaphore.

Another kind of communication between tasks in embedded systems is the passing of what might be called "Synchronization Information" from one task to another. "Synchronization Information" is like a command, where some commands could be positive, and some negative. For example, a negative command to a task would be something like "Please don’t print right now, because my task is using the printer." Or more generally, "I want to lock the . . . for my own use only." A positive command would be something like "I’ve detected a cardiac emergency, and I want you to help me handle it." Or more generally, "Please join me in handling . . ."

Most RTOSs offer a semaphore or mutex mechanism for handling negative synchronization (sometimes called "mutual exclusion"). These mechanisms allow tasks to lock certain embedded system resources for their use only, and subsequently to unlock the resource when they’re done.

For positive synchronization, an RTOS may offer event-flags or signals or rely on message passing for positive synchronization as well as data passing duties.

 

Intertask Communication involves sharing of data among tasks through sharing of memory space, transmission of data and etc. Few of mechanisms available for executing intertask communications includes:

• Message Queues

• Pipes

• Remote Procedural Calls (RPC)

Messages allow you to send data to one or more threads. These messages can be of almost any size and are usually implemented as a mailbox or a queue. If messages can be sent more quickly than they can be handled, the RTOS will provide message queues for holding the messages until they can be processed. This is shown in Figure6. A Message Queue is an object used for Intertask Communication through which task send or receive messages placed in a shared memory. Tasks and ISRs send and receive messages to the queue through services provided by the Kernel. A task seeking for a message from an empty queue is blocked either for a  duration or until a message is received. The sending and receiving of messages to and from the queue may follow 1) First In First Out (FIFO), 2) Last in First Out (LIFO) or 3) Priority (PRI) sequence. Usually, a message queue comprises of an associated queue control block (QCB), name, unique ID, memory buffers, queue length, maximum message length and one or more task waiting lists. A message queue with a length of 1 is commonly known as a mailbox.

A Pipe is an object that provide simple communication channel used for unstructured data exChange among tasks. A pipe can be opened, closed, written to and read from. Traditionally, a pipe is a unidirectional data exChange facility. There are two descriptors respectively at each end of the pipe for reading and writing. Data is written into the pipe as an unstructured byte stream via one descriptor and read from the pipe in the FIFO order from the other. Unlike message queue, a pipe does not store multiple messages but stream of bytes. In addition, data flow from a pipe cannot be prioritized.

Remote Procedure Call (RPC) component permits distributed computing where task can invoke the execution of  another task on a remote computer, as if the task ran on the same computer.

 

System Calls

A System Call is a mechanism that is used by the application programme to request a service from the Operating System. They use a machine-code instruction that causes the processor to Change mode. An example would be from supervisor mode to protected mode. This is where the Operating System performs actions like accessing hardware devices or the memory management unit. Generally the Operating System provides a library that sits between the Operating System and normal programmes. The library handles the low-level details of passing information to the Kernel and switching to supervisor mode. System Calls include close, open, read, wait and write. To actually perform useful work, a process must be able to access the services provided by the Kernel. This is implemented by the Kernel, by providing a C library or an API, which in turn invokes the related Kernel functions. The method of invoking the Kernel function varies from Kernel to Kernel. If memory isolation is in use, it is impossible for a user process to call the Kernel directly, because that would be a violation of the processor's access control rules. Few possibilities are:

•             Using a Software-Simulated Interrupt. This method is available on most hardware, and is common.

•             Using a Call Gate. A Call Gate is a special address stored by the Kernel in a list in Kernel memory at a location known to the processor. When the processor detects a call to that address, it instead redirects to the target location without causing an access violation. This requires hardware support, but the hardware for it is quite common.

•             Using a special System Call instruction. This technique requires special hardware support, which common architectures (e.g., x86) may lack. System Call instructions have been added to recent models of x86 processors and some Operating Systems for PCs make use of them when available.

•             Using a memory-based Queue. An application that makes large number of requests but does not need to wait for the result of each may add details of requests to an area of memory that the Kernel periodically scans to find requests.