RTOS(Real Time Operating System) notes

RTOS NOTES

• Hard realtime OS has less jitter and Soft real time jitter has High jitter 
• jitter : it is the time between two interrupt
• Event driven systems switch between tasks based on their priorities while time sharing systems switch the task based on clock interrupts. Most RTOS’s use a pre-emptive scheduling algorithm.
• The most common designs are
• Event-driven – switches tasks only when an event of higher priority needs servicing; called preemptive priority, or priority scheduling.
• Time-sharing – switches tasks on a regular clocked interrupt, and on events; called round robin.
• A task has three stages
• 1. Runing
• 2.Ready
• 3.Blocked(Waiting for an event,I/O for example)
• On simpler non-preemptive but still multitasking systems, a task has to give up its time on the CPU to other tasks, which can cause the ready queue to have a greater number of overall tasks in the ready to be executed state (resource starvation).
• laxity = Absolute deadline - worst case computation time
• A niceness of −20 is the highest priority and 19 is the lowest priority. The default niceness for processes is inherited from its parent process and is usually 0
• how much CPU time given to which process is depend upon nice value
• Only the superuser (root) may set the niceness to a lower value (i.e. a higher priority). On Linux it is possible to change /etc/security/limits.conf to allow other users or groups to set low nice values.
• Board support packages are used for enable services of hardware

Some commonly used RTOS scheduling algorithms are:

• Cooperative scheduling
• Preemptive scheduling
  • Rate-monotonic scheduling
  • --RMS is static (fixed)priority scheduling algorithm, static priorities assigned according to cycle duration of job so result in shorter the cycle duration higher job priority
  • --These operating systems are generally preemptive and have deterministic guarantees with regard to response times. Rate monotonic analysis is used in conjunction with those systems to provide scheduling guarantees for a particular application.
  • Threads have the following properties
  • --No resource sharing
  • --deterministic deadlines exactly equal to periods
  • --static priorities
  • --context switching times and other threads are free and have no impact on model.
  • Round-robin scheduling
  • Fixed priority pre-emptive scheduling, an implementation of preemptive time slicing
  • Fixed-Priority Scheduling with Deferred Preemption
  • Fixed-Priority Non-preemptive Scheduling
  • Critical section preemptive scheduling
  • Static time scheduling
• Earliest Deadline First approach
• Stochastic digraphs with multi-threaded graph traversal

Mutexes

• A (non-recursive) mutex is either locked or unlocked. When a task has locked the mutex, all other tasks must wait for the mutex to be unlocked by itsowner - the original thread. A task may set a timeout on its wait for a mutex. There are several well-known problems with mutex based designs such as priority inversion and deadlocks.
  In priority inversion a high priority task waits because a low priority task has a mutex, but the lower priority task is not given CPU time to finish its work. A typical solution is to have the task that owns a mutex at, or 'inherit,' the priority of the highest waiting task. But this simple approach gets more complex when there are multiple levels of waiting: task A waits for a mutex locked by task B, which waits for a mutex locked by task C. Handling multiple levels of inheritance causes other code to run in high priority context and thus can cause starvation of medium-priority threads.
  In a deadlock, two or more tasks lock mutex without timeouts and then wait forever for the other task's mutex, creating a cyclic dependency. The simplest deadlock scenario occurs when two tasks alternately lock two mutex, but in the opposite order. Deadlock is prevented by careful design.

Message passing

The other approach to resource sharing is for tasks to send messages in an organized message passing scheme. In this paradigm, the resource is managed directly by only one task. When another task wants to interrogate or manipulate the resource, it sends a message to the managing task. Although their real-time behavior is less crisp than semaphore systems, simple message-based systems avoid most protocol deadlock hazards, and are generally better-behaved than semaphore systems. However, problems like those of semaphores are possible. Priority inversion can occur when a task is working on a low-priority mess+age and ignores a higher-priority message (or a message originating indirectly from a high priority task) in its incoming message queue. Protocol deadlocks can occur when two or more tasks wait for each other to send response messages.

Memory Allocation

Whenever possible, all required memory allocation is specified statically at compile time.

In RTOS dynamic memory allocation is not used because there may be chance of memory leakage

Another reason to avoid dynamic memory allocation is to avoid internal memory fragmentation

also need of allocating chunks of memory continuously.

Because mechanical disks have much longer and more unpredictable response times, swapping to disk files is not used for the same reasons as RAM allocation discussed above.

The simple fixed-size-blocks algorithm works quite well for simple embedded systems because of its low overhead.

• VX works is example of RTOS
• interrupt polling is not a part of a RTOS
• Interrupt latency is also called interrupt response it is time required for interrupt signal from interrupt controller (i.e time from arrival of interrupt) to execution of first instruction of ISR handler
• interrupt response = interrupt latency + context saving time

Jitter(simply it is Variations)

+interrupt jitter

The variation in interrupt latency is called interrupt jitter.

+scheduling jitter

-time from completion of ISR and invocation of scheduler is called as "scheduling latency"

-The variation in scheduling latency is called as "scheduling jitter"

Priority Inversion

Let us suppose process A allocates a particular resource i.e  currently resource is locked by process A

and if there is another high priority process is arrived and it also want to acquire same resource then process B has to wait until Process A is unlock the resource this phenomenon is called as priority inversion.

• to avoid priority inversion we use 
• priority Inheritance 
• --in this low priority process in increased upto higher level priority process
• priority celing
• RTAI tasks types

• --one shot and periodic
• FIFO is the IPC mechanism used to communicate between RTAI task and linux process
• to create real time task in RTAI-- rt_task_init()

RTOS	GPOS
RTOS has unfair scheduling i.e scheduling is based on priority.	GPOS has fair scheduling i.e it can be adjusted dynamically for optimized throughput.
Kernel is pre-emptive either completely or up to maximum degree.	Kernel is non-preemptive or has long non-preemptive code sections.
Priority inversion is a major issue.	Priority inversion usually remains unnoticed.
It has a predictable behavior.	There is no predictability.
It works under worst case assumptions.	It optimizes for the average case.
It does not have a large memory.	It has a large memory.

RT_SEM s tsemaphore creation

1. create fifo rt_task_slice()
2.create semaphore rt_sem_p( , &s)
3.info about current task rt_task_inquire()
4.delete the task rt_task_delete()
5.inside main take sigaction
6.create sem with count 0
7.rt_task_create()
8.start the task
9.broadcast semaphore
10.delete semaphore


Periodic tasks, typically used in control and signal processing applications, have hard deadlines. Tasks with irregular arrival times are aperiodic tasks. ... Anaperiodic task typically has a soft deadline. Aperiodic tasks that have hard deadlines are called sporadic tasks.