Chap: 3

Introduction to Real Time Operating

System Concepts
 Content

1. Introduction of RTOS
2. Task and Task States,
3. Semaphore
4. Mutex
5. Mailboxes
6. Message Queue
7. Pipes
8. Signals
9. Timers
10.Memory Management
11.Priority Inversion Problem

By: Vikram Kulkarni

By: Vikram Kulkarni
By: Vikram Kulkarni
By: Vikram Kulkarni
By: Vikram Kulkarni
By: Vikram Kulkarni
By: Vikram Kulkarni
By: Vikram Kulkarni
By: Vikram Kulkarni
By: Vikram Kulkarni
 Tasks and Task States
• A task is the basic building block of software in an RTOS and is usually a
subroutine.
• The RTOS starts a task by specifying its corresponding subroutine, priority,
stack etc.
• The task can have 3 states :-
1. Running – The task code is currently being executed by the microprocessor. Except in
multi-processor systems, only one task is in running state.
2. Ready – The task is waiting to execute but another task is currently running.
3. Blocked – The task cannot run even if the microprocessor is free. It might be waiting
for an external event or a response. e.g. a push-button task stays blocked until the
button is pushed.
• Most RTOSs have other states like suspended, waiting, dormant etc. but
these are just sub-divisions of one of the three states above.

By: Vikram Kulkarni

By: Vikram Kulkarni
By: Vikram Kulkarni
By: Vikram Kulkarni
By: Vikram Kulkarni
By: Vikram Kulkarni
By: Vikram Kulkarni
By: Vikram Kulkarni
By: Vikram Kulkarni
By: Vikram Kulkarni
By: Vikram Kulkarni
 Some common questions about the scheduler and task states are :-

 How does a scheduler know that a task is blocked or unblocked?

 The task calls RTOS functions to indicate which functions it is waiting for and if they have
happened.

 What if all tasks are blocked?

 It is the user’s responsibility to ensure this doesn’t happen. Unless an interrupt or event
unblocks a task, tasks will stay in this state (deadlock).

 What if two tasks with same priority are ready?

 Depends on the RTOS. Some require distinct priorities, some time-slice between the 2 tasks.

 If a higher priority task unblocks, is the current running task moved to the ready state right
away?
 This will happen only if the RTOS is preemptive.

By: Vikram Kulkarni

 Mutex Functionality
• The mutex behaves like a token (key) and it restricts access to a resource.
• If a task wants to access the protected resource it must first acquire the token.
• If it is already taken, the task could wait for it to become available.
• Once obtained, the token is owned by the task and is released once the task is finished using the
protected resource.

These are the common operations that an RTOS task can perform with a mutex:

• Create\Delete a mutex
• Get Ownership (acquire a lock on a shared resource)
• Release Ownership (release a lock on a shared resource)

Fig. 1 State diagram of a mutex

As embedded system designers, it is our job to identify the critical sections of
the program and use mutexes to protect them.

By: Vikram Kulkarni

 Semaphores and Shared Data

• Semaphores are one way of protecting shared variables.

• Name is derived from the old railroad days when they were used to share a segment of rail
between more than one train.

RTOS Semaphores
• Consider two functions for dealing with the RTOS binary semaphores – TakeSemaphore and
ReleaseSemaphore.
• If a task has called TakeSemaphore to take the semaphore, any other task calling it will block
until the semaphore is released (ReleaseSemaphore).
By: Vikram Kulkarni
 Semaphores and Shared Data(Cont.)
• With this new setup consider the scenario where the ‘levels task’ has just taken
the semaphore and is pre-empted by the higher priority ‘push button’ task.
• The RTOS will move the higher priority task to the running state.
• When this task tries to lock the semaphore, it will block.
• The OS will then run the task which has the semaphore (levels task) until it releases it.
• As soon as this happens, the RTOS will switch back to the higher priority task which is now
unblocked.

Multiple Semaphores
• RTOSs normally allow the users to have multiple semaphores that are distinctly identified by a
parameter and are independent of each other.
• This speeds task responses – a high priority task does not have to be blocked by a lower priority
one as long as it is using a different semaphore.
• It is the users responsibility to remember which semaphore protects which shared data – the OS
will not do that.
By: Vikram Kulkarni
 Semaphores and Shared Data(Cont.)
Semaphores Problems
• Forgetting to take it – Semaphores only work if tasks actually remember to use them while
accessing shared data.
• Forgetting to release the semaphore – This will cause all tasks using the semaphore to be
eventually blocked forever.
• Holding it for too long – Higher priority tasks might loose their deadlines if some lower priority
task holds the semaphore for too long.
A problem that can happen is if a low priority task C has a semaphore and a higher priority task
B that does not use the semaphore pre-empts it in between.
Now suppose the highest priority task A comes along and is blocked on the semaphore. As B
has a higher priority than C it will run instead and might block A for long enough that it misses
its deadline.
This is called priority inversion. Some RTOSs temporarily give task A’s priority to C (and hence
prevent B from pre-empting C).

By: Vikram Kulkarni

 Semaphores and Shared Data(Cont.)
Semaphores Variants
• Some systems allow semaphores that can be taken multiple time. Taking them decrements their
count and releasing increments it. They are hence called counting semaphores
• Semaphores that can only be released by the task that took them are resource semaphores. Though
they prevent shared-data bugs, they cannot be used for task inter-communication.
• A semaphore that deals with priority inversion is commonly called a mutex semaphore or mutex
(mutually exclusive).

Methods to Protect Shared Data

• The 2 basic methods are disabling interrupts and using semaphores.
• A third method is disabling task switches, but this has no effect on interrupt routines.
• Note – interrupts are not allowed to take semaphores so they cannot be used if the data is shared
between the task code and the ISR.

By: Vikram Kulkarni

 Message Queues, Mailboxes, and Pipes
• Besides shared variables and semaphores, tasks can communicate with each other using queues, mailboxes
and pipes.
• E.g. if there are 2 tasks Task1 and Task2 that have to report each error they encounter, they can do so by
reporting it through a queue to a separate ErrorsTask and going back to their own functions.
• ErrorsTask can be lower priority and hence the two main tasks are not delayed.

Important Points
• Most RTOS require queues to be initialized before being used. Some OSs also require the user to allocate
memory for them.
• If a task tries to write to a queue that is full, the RTOS generally returns an error, or in some cases it might
block the task until another task reads the queue. The code should deal with these errors.
• RTOSs include functions that read from queues, if they have data, and return an error if they don’t.
• Many RTOSs only allow a fixed amount of data that can be written in one call.
• A common method is to allow the user to write the number of bytes taken up by a void pointer in one
function call.

By: Vikram Kulkarni

 Message Queues, Mailboxes, and Pipes
(contd.)
Pointers and Queues
• Void pointer is used to write to the queue.
• nodes who want to send only a small amount of data can typecast the data as a void pointer.
• Another method involves allocating a data buffer (using malloc) and passing a pointer to that buffer to the queue.

Mailboxes
• Mailboxes are similar to queues. They have variations in different RTOS as follows :-
• Most RTOS allow only one message in a mailbox though some might allow more.
• Some OS have unlimited message length mailboxes. The total messages in all the mailboxes however is limited and
this is distributed among individual mailboxes.
• Some RTOS allow priorities in mailboxes – higher priority mailboxes will be read first

By: Vikram Kulkarni

Pipes
• Pipes are also similar to queues. Like mailboxes they have variations in different RTOSs.
• Some RTOSs allow variable message lengths to be written to pipes.
• In some RTOSs pipes are byte-oriented e.g. if Tasks A and B wrote 5 and 10 bytes respectively to the pipe
and if Task C reads 7 bytes, it will get 5 bytes of A and 2 of B. The remaining bytes of B will remain in the
pipe
• Some RTOSs use C library functions fread and fwrite to read and write to pipes

Which to Use?
• Since queues, mailboxes and pipes vary in each RTOS, the user should read the corresponding documentation
and determine which would best suit his communication requirement.

Pitfalls
• Although the above 3 mechanisms simplify sharing data they can also introduce several bugs.
• User should ensure that tasks write to the correct mailboxes otherwise there might be errors.

By: Vikram Kulkarni

 Timer Functions
• Embedded systems generally require to track time.
• Example:
• A cell phone preserves battery by turning its display off after a few seconds.
• Network connections re-transmit data if an acknowledgement is not received within a certain period.

• Most RTOSs have a delay function that delays or blocks a task for a certain time period.
• e.g. in the U.S. each of the tones representing a digit in a phone call must sound for 1/10th of a second followed by the same period of
silence between tones.

This can be done by utilizing the function taskDelay(100) that delays the task for 100ms
Questions
• How do I know that taskDelay takes milliseconds as its parameter?
You don’t. In VxWorks for e.g. taskDelay takes system ticks as the parameter
• How accurate are these delays?
They are accurate to the nearest tick. The RTOS sets up a hardware timer often called a heartbeat timer to
periodically interrupt and bases its timings on the interrupt.

By: Vikram Kulkarni

 Timer Functions
• How does the RTOS know how to setup the timer hardware ?
• RTOSs are microprocessor-dependent and hence the engineers that wrote the RTOS know which processor it
will run on and hence can program the corresponding timer.
• If the timer hardware is non-standard, the user is required to write his/her own timer setup and interrupt
routines that will be called by the RTOS.
• Many vendors provide board support packages (BSPs) that help users to write driver software for any special
hardware they are using
• What is the “normal length” for a system tick?
• There isn’t one. Short system times provide accurate timings with the added disadvantage of occupying the
processor more and reducing throughput.
• The designer must make a trade-off between the two.
• What if the system requires extremely accurate timing?
• The user can either use short system ticks or use a separate dedicated hardware timer for functions requiring
accurate times and the RTOS for all other timings.
• The advantage of using the OS is that one timer handles many operations simultaneously.

By: Vikram Kulkarni

Timer Functions (contd.)
Other Timing Services
• RTOSs offer many timing services based on the system tick like deciding the time, a task, should wait on a
semaphore or mailbox etc.
• However user should exercise caution e.g. a higher priority task might timeout waiting on a semaphore and not
get the shared data. The user code should handle such potential problems. A better design would be to allow a
lower priority task get the shared data so the high priority task can continue its work.
• The code is written in VxWorks and basically handles hardware for a radio.
• Turning off the radio only requires turning the power off, however turning it on requires :–
• First the power must be turned on.
• After 12 ms the radio frequency must be set
• 3 ms later the transmitter or receiver can be turned on and the radio is ready.

By: Vikram Kulkarni

 Memory Management
• RTOSs prefer allocating and freeing fixed-size buffers rather than using C functions like malloc and free, as they are faster
and more predictable.
• The MultiTask! RTOS consists of pools that have a certain number of same-size memory buffers.
• reqbuf and getbuf allocate a buffer from the pool. The difference between the two is that the former returns a NULL
pointer if the pool is empty while the latter blocks the task

void *getbuf (unsigned int PoolId, unsigned int Timeout);

void *reqbuf (unsigned int PoolId);
void relbuf (unsigned int PoolId, void *p_vBuffer);

• The buffer size returned depends on the pool. relbuf frees a buffer
• MultiTask! like typical RTOSs needs to be told where the memory is (init_mem_pool).
int init_mem_pool (
unsigned int PoolId,
void *p_vMemory,
unsigned int BufSize,
unsigned int BufCount,
unsigned int PoolType);
By: Vikram Kulkarni
 Memory Management (contd.)

• PoolId – identifier
• p_vMemory – points to the pool memory block
• BufSize and BufCount – indicate size and count of buffer
• PoolType – indicates if buffers will be used by tasks or by interrupt
routines.

By: Vikram Kulkarni

 Priority Inversion
Priority inversion is a operating system scenario in which a higher priority process is blocked by a lower
priority process. This implies the inversion of the priorities of the two processes.

Problems due to Priority Inversion

Some of the problems that occur due to priority inversion are given as follows −
• A system malfunction may occur if a high priority process is not provided the required resources.
• Priority inversion may also lead to implementation of corrective measures. These may include the
resetting of the entire system.
• The performance of the system can be reduces due to priority inversion. This may happen because
it is imperative for higher priority tasks to execute promptly.
• System responsiveness decreases as high priority tasks may have strict time constraints or real
time response guarantees.
• Sometimes there is no harm caused by priority inversion as the late execution of the high priority
process is not noticed by the system.

By: Vikram Kulkarni

 Solutions of Priority Inversion

Some of the solutions to handle priority inversion are given as follows −

• Priority Ceiling All of the resources are assigned a priority that is equal to the highest priority of any
task that may attempt to claim them. This helps in avoiding priority inversion.
• Disabling Interrupts There are only two priorities in this case i.e. interrupts disabled and
preemptible. So priority inversion is impossible as there is no third option.
• Priority Inheritance This solution temporarily elevates the priority of the low priority task that is
executing to the highest priority task that needs the resource. This means that medium priority tasks
cannot intervene and lead to priority inversion.
• No blocking Priority inversion can be avoided by avoiding blocking as the low priority task blocks the
high priority task.
• Random boosting The priority of the ready tasks can be randomly boosted until they exit the critical
section
By: Vikram Kulkarni
 Thanks

By: Vikram Kulkarni