08.705 rtos module 3 notes.docx

08.705 RTOS Module 3

Real Time Kernels To understand real-time kernel design and development, consider a simple real-time kernel called

DICK (DIdactic C Kernel) DICK is written in C language, able to handle periodic and aperiodic tasks with explicitly time

constraints.Structure of Real-Time Kernels

A kernel represents the innermost part of OS that is in direct connection with the hardware of the physical machine.

The basic activities of kernel are:1. Process management2. Interrupt handling3. Process synchronization.

Process management: Primary service of OS. Provides various supporting functions, such as process creation and termination, job scheduling,

dispatching, context switching, and other related activities.Interrupt handling:

Provide service to the interrupt requests that may be generated by any peripheral device, such as the keyboard, serial ports, analog-to-digital converters, etc.

It executes dedicated ISR. In real-time system, it is integrated with scheduling mechanism.

Process synchronization and communication: It provides synchronization and communication between processes via semaphore, messages,

queues, pipelines etc.Hierarchical level structure of DICK:

1. Machine layer: Lowest level and directly interact with hardware. Written in assembly language. Not visible to users. Deals with context switching, interrupt handling, timer handling etc.

Department of ECE, VKCET


2. List management layer: Keep track the status of various tasks. Manage the task according to its state. Provide preemption to tasks.

3. Processor management layer: Provides scheduling and dispatching operations.

4. Service layer: Provides all services visible at the user level as a set of system calls. Typical services concern task creation, task abortion, suspension of periodic instances,

activation and suspension of aperiodic instances, and system inquiry operations. Process states

Kernel that supports the execution of concurrent activities on a single processor, where semaphores are used for synchronization and mutual exclusion, there are at least three states in which a task can enter:

1. RUNNING : Task enter into executing on the processor2. READY : Task ready to executes, ready to execute but cannot be executed because the

processor is assigned to another task.3. WAITING : Task enter into this state, when it is wait for an event, to take a semaphore, to

read a queue etc. In a real-time kernel, to execute periodic tasks, another state must be considered called IDLE

state. A periodic job enters this state when it completes its execution and has to wait for the beginning of the next period. Usually a periodic task is put into IDLE state by the system call for end cycle and is awakened from it by the timer. The timer verifies, at each tick, whether some job has to be awakened.

The state transition diagram relative to the four states are shown below:

An additional state introduced by other kernel services are:1. DELAY : It suspends the task for a given interval of time and put it on a sleep state. The

task will awakened by the timer after the elapsed interval.2. RECEIVE : It is for message passing. A task enter into this state when it executes a

receive primitive on an empty channel. The task exits from this state when a send primitive is executed by another task on the same channel.

3. ZOMBIE : It is the state to kill the time. To keep the guarantee test consistent, the utilization factor of an aborted task can be subtracted from the total load only at the end of the current period. It is the interval of time between the abort operation and the end of



its period. Such state does not exist in the system, but it continues to occupy processor bandwidth. An illustration is shown below:

A more complete state transition diagram including all these states is illustrated below:

The state transition diagram in DICK is shown below:



In DICK, RECEIVE and DELAY states are not present. It has SLEEP state which is used to activate or sleep aperiodic tasks.

An aperiodic task enters the SLEEP state by executing the sleep primitive and a task exits the SLEEP state and goes to the READY state only when an explicit activation is performed by another task.

Data Structures:TCB

The information about a task are stored in a data structure, called Task Control Block(TCB). TCB contains all the parameters specified by the programmer at creation time, and other

temporary information necessary to the kernel for managing the task. Typical fields of a TCB in real-time system are:

1. Task identifier: It is a character string used by the system to refer the task in messages to the user,

2. Task address: The memory address corresponding to the first instruction of the task.3. Task type: The task type (periodic, aperiodic, or sporadic).4. Task criticalness: The task criticality (hard, soft, or non-real-time).5. Task priority: The priority (or value), which represents the importance of the task with

respect to the other tasks of the application.6. Task state: The current state (ready, running, idle, waiting, and so on).7. Task computation time: The worst-case execution time ( Ci ).8. The task period: The period of periodic task.9. The relative deadline: The deadline specified by the user.10. The absolute deadline: The absolute deadline computed by the kernel at the arrival time.11. The task utilization factor (only for periodic tasks).



12. A pointer to the process stack, where the context is stored.13. A pointer to a directed acyclic graph (DAG), if there are precedence constraints.14. A pointer to a list of shared resources, if a resource access protocol is provided by the kernel.

In DICK, a TCB is an element of the vdes[MAXPROC] array, whose size is equal to the maximum number of tasks handled by the kernel.

SCB Another data structure contains information concerning a semaphore is stored in a Semaphore

Control Block (SCB). Which contains at least the following three fields :

1. A counter : Represents the value of the semaphore.2. A queue : Enqueueing the tasks blocked on the semaphore.3. A pointer : To point the next SCB, to form a list of free semaphores.

In DICK, SCB is an element of the vsem[MAXSEM] array, whose size is equal to the maximum number of semaphores handled by the kernel.

Kernel Primitives They are used for implementing the kernel services at different levels. Different kernel primitives are:

1. Low level primitives2. List management primitives3. Scheduling mechanism primitives4. Task management primitives5. Semaphores primitives6. Status enquiry primitives



Low level primitives: To implement the mechanism for saving and loading the context of a task, ie for values of

processor registers. The primitives are save_context and load_context and there code are shown below:



List management primitives: Different list management primitive functions are insert, extract, getfirst, firstdline and empty.

insert: It insert a task in a queue based on its deadline. It is called with two parameters, the index of the task to be inserted and pointer of the queue. It uses two auxiliary pointers p and q and its meaning is illustrated below.



extract: It extract a task from the queue. Its illustration is shown below:

getfirst: It extract a task from the head of the queue. Its illustration is shown below:



firstdline: It returns the deadline of the first task. Its illustration is shown below:

empty: It returns TRUE, if a queue is empty. Its illustration is shown below:

Schedule management primitives: The primitive functions for scheduling mechanisms in DICK are: schedule, dispatch and

wake_up.schedule: It verifies whether the running task is the one with the earliest deadline. If so, there is no action, otherwise the running task is inserted in the ready queue and first ready task is dispatched. Its illustration is shown below:



dispatch: It assigns the CPU to the first ready task. Its illustration is:

wake_up: It is the ISR performs the activities for time management. It increments the sys_clock variable, checks for system lifetime and possible deadline misses, remove those tasks in zombie state and resume those periodic tasks in idle state at the beginning of their next period. Its illustration is shown below:



Task management primitives It concerns creation, activation, suspension, and termination of tasks. Different functions for primitives are: create, guarantee, activate, sleep, end_cycle, end_process

and kill.create: It creates a task and put it in SLEEP state. Its illustration is shown below:



guarantee: It guarantees the feasibility of a hard task. Its illustration is shown below:

activate: It inserts a task in the ready queue. Its illustration:

sleep: It suspends itself in a SLEEP state. Its illustration:



end_cycle: It inserts a task in the IDLE queue. Its illustration:

end_process: It terminates the running task. Its illustration:



kill: It terminates a task. Its illustration:

Semaphores primitives: In DICK, synchronization and mutual exclusion are handled by semaphores. There are four primitives are provided: newsem, delsem, wait and signal

newsem: It allocates a free semaphore control block and initializes the counter field to the value passed as a parameter.

delsem: It deallocates the semaphore and inserting it in the list of free semaphores.

wait: It is used by a task to wait for an event associated with a semaphore. If the semaphore counter is positive, it is decremented, and the task continues its execution; if the counter is less than or equal to zero, the task is blocked, and it is inserted in the semaphore queue. In this case, the first ready task is assigned to the processor by the dispatch primitive.

signal: It is used by a task to signal an event associated with a semaphore.

Status inquiry primitives: These primitives are for inquiring the kernel about internal variables and task parameters.

get_time: It returns the system time in milliseconds.

get_state: It returns the state of a task.

get_dline: It returns the deadline of a task



get_period: It returns the period of a task

Intertask Communication Mechanism: Intertask communication is a critical issue in real-time systems It is necessary to use the shared resources for implementing message passing and may cause

priority inversion and unbounded blocking on tasks’ execution. There are two types of communication model: synchronous and asynchronous. In pure synchronous communication model, whenever two tasks want to communicate they must

be synchronized for a message transfer to take place. This synchronization is called a rendezvous. Thus, if the sender starts first, it must wait until the recipient receives the message; on the other hand, if the recipient starts first, it must wait until the sender produces its message.

In a dynamic real-time system, synchronous communication results unpredictable behavior, due to the difficulty of estimating the maximum blocking time for a process rendezvous.

In a static real-time environment, the problem can be solved off-line by transforming all synchronous interactions into precedence constraints. According to this approach, each task is decomposed into a number of subtasks that contain communication primitives not inside their code but only at their boundary.

An example of a task decomposition is illustrated below:

In a pure asynchronous scheme , communicating tasks do not have to wait for each other. The sender just deposits its message into a channel and continues its execution, independently of the recipient condition.

Asynchronous communication schemes are more suitable for dynamic real-time systems. In most commercial RTOS, the asynchronous communication scheme is implemented through a

mailbox mechanism as shown below:

Two basic operations are provided on a mailbox: send and receive. A send(MX, mes) operation causes the message mes to be inserted in the queue of mailbox MX. If at least a message is



contained on mailbox MX,a receive(MX, mes) operation extracts the first message from its queue.

Mailbox provides only a partial solution to the problem of asynchronous communication, since it has a bounded capacity. Thus, if the queue is full, the sender must be delayed until some message is received. If the queue is empty, the receiver must wait until some message is inserted.

Cyclic Asynchronous Buffers (CAB) Avoid the limitation of mailbox for asynchronous communication. CAB provides a one-to-many communication channel, which at any instant contains the latest

message or data inserted in it. A message is not consumed by a receiving process but is maintained into the CAB structure until

a new message is overwritten. As a consequence, once the first message has been put in a CAB, a task can never be blocked

during a receive operation. Similarly, since a new message overwrites the old one, a sender can never be blocked.

In this a message can be read more than once if the receiver is faster than the sender, while messages can be lost if the sender is faster than the receiver. This is not a problem in many control applications; where tasks are require current data rather than previous ones.

CAB primitives are: open_cab for create and initial CAB, delete_cab to remove a CAB from the system and releases the memory space.

The data structure used to implement a CAB is shown below:

CAB control block contains: max_buf – store maximum number of buffers, dim_buff – dimension of buffer, free – a pointer to a list of free buffer and mrb – pointer to recent buffer.

Each buffer in the CAB can be implemented as a data structure with three field: next – a pointer to maintain a list of free buffers, use – stores the current number of task accessing that buffer and data - a memory area for storing message.



System overhead The overhead of an OS represents the time used by the processor for handling all kernel

mechanisms, such as enqueueing tasks, performing context switches, updating the internal data structures, sending messages to communication channels, servicing the interrupt requests, and so on.

The time required to perform these operations is usually much smaller than the execution times of the application tasks. So it can be negligible comparing to execution time of application tasks.

If execution time of tasks is very small and has tight timing constraints, then activities performed by the kernel may not be so negligible and may create significant interference on the task’s execution.

In such situations, predictability can be achieved only by considering the effects of the runtime overhead in the schedulability analysis.

Different overhead factors are:1. Context switching : One of the most significant overhead factors in any OS. It is an intrinsic

limit of the kernel that does not depend on the specific scheduling algorithm, nor on the structure of the application tasks.

2. Execution time of ISR : It is another important overhead factor in real-time system. If Q is the system tick (ie the period of the interrupt request from the timer) and σ is the worst-case execution time of the ISR, then timer overhead can be computed as the utilization factor U t of an equivalent periodic task.

The illustration shows the execution interval σ due to the timer routine and execution intervals δ necessary for a context switch.

The effect of ISR schedulability of a periodic task also takes for task utilization factor Ut. The net bound of utilization factor becomes

Where Ulub is upper bound of the utilization factor. This shows that Unet > 0, system tick Q always greater than σ/Ulub.



The plot of Unet as a function of Q is shown below:

The overhead due to other kernel mechanisms can also be taken for the performance. It is like the context switches during the execution of kernel primitives.

If Ni is the maximum number of preemptions that a periodic task of period T i and δ is the time needed to perform a context switch, the total utilization factor is given as,

Hence we can write

Where Up is the utilization factor of the periodic task set and Uov is a correction factor that considers the effects of the ISR and the preemption overhead due to context switches.

Case study of RTOSQNX Neutrino 2 RTOS

It is commercial RTOS with very small kernels (micro kernel) with a memory footprint of a few kilobytes

It provides support for concurrency through processes and/or threads. Applications: Mission-critical applications like medical instruments, Internet routers, telematics

devices, process control applications, air traffic control systems etc. QNX Neutrino microkernel implements only the most fundamental services in the kernel, such as

signals, timers, and scheduling. All other components file systems, drivers, protocol stacks, applications run outside the kernel, in

a memory-protected user space. Due to this, a faulty component can be automatically restarted without affecting other components or the kernel.

Some of the real-time features include distributed priority inheritance to eliminate priority inversion and nested interrupts to allow priority driven interrupt handling.

All components communicate via message passing, which allows the user to dynamically plug in, or plug out, any component during execution.



It provides support for transparent distributed processing using standard messages to access hardware and software resources on remote nodes.

QNX Neutrino also provides advanced graphics features to create visual applications for markets such as automotive, medical, industrial automation and interactive gaming.

It also support accelerated 3D graphics allows for the creation of sophisticated displays with little impact on CPU performance.

Micro C/OS II RTOS μCOS stands Micro Controller OS. Also known as MUCOS or MicroCOS or UCOS. Non-commercial use, freeware and available from Micrium. It is a very small real-time kernel and requires only 20KB memory for a fully functional kernel. Source code is written mostly in C. Highly portable, ROMable, very scalable, preemptive real-time, deterministic, multitasking

kernel. Applications: Automotive, avionics, consumer electronics, medical devices, military, aerospace,

networking, SoC development An advantage of using this RTOS is full source code availability It is simple to use and simple to implement but very effective compared to the price/performance

ratio. It supports all type of processors from 8-bit to 64-bit. MicroC/OS-II is the second generation of a kernel originally published (with source code)


08.705 rtos module 3 notes.docx

Documents

task ready

task abortion

realtime kernel

idle state

process states kernel

kernel services

additional state

sleep state