1. Real Time Operating Systems
Introduction to
Real-Time Operating Systems
(Part II)
Course originally developed by
Maj Ron Smith

2. Outline Multitasking Scheduling Resource Sharing (Mutual Exclusion)
tasks, kernels, context switching
Scheduling
types, priorities, interrupts, the “tick”
Resource Sharing (Mutual Exclusion)
reentrancy, techniques (semaphores), deadlock
Intertask Communication
queues and mailboxes
24-Apr-17
Dr Alain Beaulieu

3. Multitasking multitasking
the process of scheduling the CPU between several sequential tasks
maximizes CPU usage
provides for modular construction of programs
facilitates real-time application development
the tough part: selecting and organizing the tasks
24-Apr-17
Dr Alain Beaulieu

4. Multitasking task (thread of control)
a process which thinks it has the CPU all to itself
has priority, its own set of CPU registers and its own stack
typically, an infinite loop in one of 5 states:
dormant, ready, running, waiting or interrupted
types of tasks:
“fast service” operation
suspended awaiting event (keyboard)
periodic service
background, after everything else (display update)
Draw process 3 states diagram and the other.
24-Apr-17
Dr Alain Beaulieu

5. Multitasking kernel (RTOS)
responsible for the management of tasks and communication between tasks
its fundamental service is to facilitate task switching (context switching)
adds overhead to the system
ROM & RAM
RAM per task
2-5% CPU usage
saves the developer from having to write code for services such as mutual exclusion, mailboxes, queues, time delays, etc..
24-Apr-17
Dr Alain Beaulieu

6. Multitasking context switch when a task switch is decided upon:
the context (CPU registers) of the executing task is saved in its context storage area (the task control block) on its stack
the new task’s context is restored from its storage area on its stack
execution of the new task is initiated (based upon its context)
when a task switch occurs, depends upon the scheduling policy of the kernel (as we’ll see later)
24-Apr-17
Dr Alain Beaulieu

7. Multitasking - context switch
Task n
stack
stack
stack
...
tcb
tcb
tcb .
priority
task ID
stack pointer .
priority
task ID
stack pointer .
priority
task ID
stack pointer
Memory
CPU
context
CPU registers
Dr Alain Beaulieu
24-Apr-17

8. Multitasking - context switch
task control block
ready queue
next task .
priority
taskID
stack pointer .
priority
task ID
stack pointer
head .
priority
task ID
stack pointer
running task .
priority
task ID
stack pointer
Idle task .
Dr Alain Beaulieu
24-Apr-17

9. Scheduling - types non-preemptive (cooperative multitasking)
tasks decide for themselves when to give up the CPU; either when completed or explicitly
asynchronous events are handled using interrupts
tasks still have an assigned priority
advantages:
- interrupt latency time is low
- less need to “guard” shared resources
disadvantages:
- responsiveness is non-optimal & non-deterministic
- one task may lock-up system
Do not have to go through the ready queue
24-Apr-17
Dr Alain Beaulieu

10. Scheduling - types (non-preemptive)
low priority task
ISR makes high
priority task ready
(1)
(2)
ISR
(3)
(4)
Time
(5)
(6)
high priority task
low priority task
relinquishes CPU
(7)
Ref [2]
Dr Alain Beaulieu
24-Apr-17

11. Scheduling - types preemptive
the highest priority task (ready) is given control of the CPU
current running task is suspended
after an Interrupt Service Routine (ISR), the new highest priority task is run
advantages:
- responsiveness is optimal & deterministic
disadvantages:
- shared resources must be properly guarded
24-Apr-17
Dr Alain Beaulieu

12. Scheduling - types (preemptive)
low priority task
ISR makes high
priority task ready
(1)
(2)
ISR
(3)
(4)
high priority task
Time
(5)
(6)
high priority task
is switched in
(7)
Ref [2]
Dr Alain Beaulieu
24-Apr-17

13. Scheduling - types round-robin (time-slicing)
special case of preemptive
tasks with the same priority are only allowed to run for a predetermined time period, “a quantum”
task switching then occurs giving each same priority task equal opportunity at the CPU
not necessarily supported by all preemptive kernels
microC/OS-II does not support round-robin
24-Apr-17
Dr Alain Beaulieu

14. Scheduling - priorities
static
the priority of a task is set at compile time and does not change during application execution
advantage:
all timing constraints can be known at compile time
disadvantage:
may get priority inversion
dynamic
each task can change its priority during execution
useful in avoiding priority inversion
not easy to guarantee schedulability
24-Apr-17
Dr Alain Beaulieu

15. Scheduling - priorities
assigning task priorities
non-trivial
based upon the soft and hard real-time requirements
based upon the type of scheduling policy
interrelated to kernel selection
requires detailed knowledge of kernel and processor latency and response times
involves schedulability* analysis and techniques
for example rate monotonic scheduling
*covered later
Also has some basis in control theory system dynamics and kinematics
24-Apr-17
Dr Alain Beaulieu

16. Scheduling - interrupts
Interrupts and ISRs
a hardware mechanism to inform the CPU that an asynchronous event has occurred
the CPU partially saves its context and jumps or vectors to an interrupt service routine (ISR)
return from interrupt is to:
the interrupted task for non-preemptive kernels
the highest priority task for preemptive kernels
interrupts may be nested
interrupts may be disabled / enabled in software
Nonmaskable Interrupt
can not be disabled via software
Explain that the OS does not have the control of the CPU, so the CPU must save the context (PC would be lost)
Will show in the lab
24-Apr-17
Dr Alain Beaulieu

17. Scheduling - the “tick” or quantum
the clock tick
a special interrupt that occurs periodically
polling versus pushing (keyboard example)
the time between interrupts is application specific
generally between 10 and 200 milliseconds
allows the kernel to delay tasks for integral numbers of ticks or provide timeouts awaiting events
resolution of delayed tasks is one clock tick
the accuracy is not one clock tick
the faster the tick rate, the greater the accuracy but the higher the system overhead
24-Apr-17
Dr Alain Beaulieu

18. Mutual Exclusion - reentrancy
a function is defined as being reentrant if more than one task can use it without fear of data corruption
in other words it can be interrupted, followed by a context switch, and subsequently resumed without loss of data
a function can be made reentrant with local variables or through the use of protected global variables
24-Apr-17
Dr Alain Beaulieu

19. Reentrant Function Example
non-reentrant
int temp; // global
function swap(int *x, int *y) {
temp = *x;
*x = *y;
*y = temp; }
reentrant version
function swap (int *x, int *y) {
int temp; // local
temp = *x;
*x = *y;
*y = temp; }
24-Apr-17
Dr Alain Beaulieu

20. Mutual Exclusion - techniques
besides shared functions, we must also deal with other shared resources such as global data stores, buffers, I/O devices, etc
techniques to address mutual exclusion include:
disabling/enabling interrupts
disabling scheduling
performing test-and-set operations (indivisibly)
using semaphores
24-Apr-17
Dr Alain Beaulieu

21. Mutual Exclusion - techniques
disabling/enabling interrupts
used to access a few variables or small data structures
used when the process time is minimal
affects interrupt latency
you should not disable interrupts for any longer than the kernel does
in C/OS-II:
OS_ENTER_CRITICAL( );
… // you can access shared data here
OS_EXIT_CRITICAL( ):
24-Apr-17
Dr Alain Beaulieu

22. Mutual Exclusion - techniques
disabling scheduling
instead of disabling all maskable interrupts, you may just want to disable the scheduler
an interrupted task is returned to, not necessarily the highest priority task
implies that data is not shared with the ISRs
in C/OS-II:
OSSchedLock( );
… // you can access shared data here
OSSchedUnlock( );
24-Apr-17
Dr Alain Beaulieu

23. Mutual Exclusion - techniques
perform test-and-set operations (indivisibly)
two tasks may agree that to use a common resource, they must first check a global variable
while it is being checked, and before it is set, by one task, it must be made inaccessible by the other
this can be achieved by:
disabling interrupts (above) or
some processors now support a single TAS instruction
this common computing problem lead to a 1965 software invention -> the ?
24-Apr-17
Dr Alain Beaulieu

24. Mutual Exclusion - semaphores
invented by Dijkstra in 1965
a protocol mechanism to control access to shared resources, signal the occurrence of an event or allow two tasks to synchronize
one analogy is that in order for a task to use a resource it must first draw a key for it
if the key(s) is in use, the task suspends
wait on (pend) & signal (post) semaphore
two types of semaphores:
binary and counting (general)
24-Apr-17
Dr Alain Beaulieu

25. Visualizing a Semaphore
task 1
3. “my name is task 1”
1. pend
Printer
4. post
2. pend
task 2
6. post
5. “my name is task 2”
Dr Alain Beaulieu
24-Apr-17

26. Semaphore Example accessing shared data in C/OS-II
OS_EVENT *SharedDataSem;
SharedDataSem = OSSemCreate(1);
...
void Function (void) {
INT8U err; //read as “char *err” (string)
OSSemPend(SharedDataSem, 0, &err);
… //access shared data
OSSemPost(SharedDataSem); }
binary semaphore
timeout value
{wait forever in this case}
event control block - the state of an event consists of the event itself (a counter for a semaphore, a pointer for a message mailbox or a array of pointers for a queue) and a list of task that are waiting for this event. Each semaphore, mailbox and queue is thus assigned an ECB.
task 1
“my name is task 1”
error message code
1. pend
24-Apr-17
Dr Alain Beaulieu
3. post
Printer
2. pend
task 2
4. post
“my name is task 2”

27. Mutual Exclusion - deadlock
a situation in which two tasks are (unknowingly) waiting for resources held by the other
avoid this situation by having tasks:
acquire all resources before proceeding
acquire all resources in the same order (across tasks)
release resources in reverse order
most kernels allow you to specify a timeout when acquiring a semaphore (with error code)
task 1 runs and obtains access to resource 1
it is interrupted by task 2
task 2 obtains access to resource 2
task 2 requests and pends on resource 1 (awaiting task 1)
task1 eventually resumes and now requests and pends on resource 2 (awaiting task 2)
DEADLOCK!
Draw the resource-process diagram Circles and Squares with directed arrows. Show the process state diagram and why they are deadlocked.
24-Apr-17
Dr Alain Beaulieu

28. Intertask Communication
Synchronization
unilateral rendezvous - one task can be synchronized with another (no data transferred) by using a semaphore
the semaphore is analogous to a flag signaling the occurrence of an event (vice a key for mutex)
in this case, the semaphore is initialized to 0
Task 2
2. Post
Task 1
1. Pend
24-Apr-17
Dr Alain Beaulieu

29. Intertask Communication
Synchronization
bilateral rendezvous - two tasks can be synchronized with each other by using two separate semaphores
3. Signal Task 1
2. wait for signal from task 2
Task 1
Task 2
4. wait for signal from task 1
1. Signal Task 2
24-Apr-17
Dr Alain Beaulieu

30. Intertask Communication
data transfer
there are two general ways in which tasks exchange data:
through global data stores, or
by sending messages
if global data is used, each task or ISR must ensure it has exclusive rights
if an ISR is involved, the only way to ensure this is through the disabling of interrupts
if two tasks are involved you can disable interrupts or use semaphores
more commonly, messages are sent between tasks
usually achieved via a message mailbox or message queue
24-Apr-17
Dr Alain Beaulieu

31. Intertask Communication
message mailbox
messages are typically pointer-sized variables
a task or an ISR can deposit a message (pointer) into a mailbox.
similarly, one or more tasks can retrieve the message from the mailbox
the sending and receiving tasks must agree on what type of data the message points to I
Task 1
1. Post
Task 2
2. Pend
100msec
24-Apr-17
Dr Alain Beaulieu

32. Intertask Communication
message mailbox (cont’d)
C/OS-II provides the following type of typical mailbox services:
initialization OSMboxCreate(...);
deposit (post) OSMboxPost(…);
wait (pend) OSMboxPend(…); //includes timeout
get (accept) OSMboxAccept(…);
query OSMboxQuery(…);
*pend will wait on message (for some timeout period, while accept will get the message if it is there but not wait for it)
24-Apr-17
Dr Alain Beaulieu

33. Intertask Communication
message queues
used to send one or more messages to tasks
it is basically an array of mailboxes
messages can be retrieved either FIFO or LIFO
a kernel will normally provide the same mechanisms for a message queue as for a message mailbox I I
Task 1
1. Post
Task 2
2. Pend 5
100msec
24-Apr-17
Dr Alain Beaulieu

34. References
[1] Cooling, J.E., “Software Design for Real-time Systems”, Chapters 1 & 9.
[2] Labrosse, J.J., “MicroC/OS-II”, Chapter 2.
[3] Furht et al, “Real-Time UNIX Systems”, Chapter 2.
[4] Greenfiled J.D., “The 68HC11 Microcontroller” Chapter 3.
[5] market/rtos/rtos.htm
fault tolerance - features which enable a system to continue functioning even in the presence of faults.
24-Apr-17
Dr Alain Beaulieu