ECT 358

1. ECT 358 Lecture 27 Real Time Operating Systems

2. Aurthority makes some people grow – and others just swell. But he that is greatest among you shall be your servant. And whosoever shall exalt himself shall be abased; and he that shall humble himself shall be exalted. Matthew 23:11-2

3. Real-Time Operating System (RTOS) • Provides standard set of services to help manage task execution • Avoids many of the problems of applying foreground/background to a`periodic systems

4. RTOS Program Structure

5. Some Definitions • Critical Section of Code • Code which must not be interrupted • Typically disable interrupts while it is executing • Task • Simple program which thinks it is executing alone in the CPS • Can be considered a thread • Each task has a priority, its own set of registers, and its own stack area • Resource • Any entity used by a task (I/O device, variable, array, memory, etc) • Shared Resource • Resource that can be used by more than one task • Task should gain exclusive use of the resource to prevent data corruption • Exclusive use is called mutual exclusion

6. Some Definitions (cont) • Multitasking • Process of scheduling and switching the CPU among several tasks • Only one task is running at any given time instant although many may be “executing” • The OS task switching mechanism allows each task to have the illusion that it has the CPU to itself • May also be considered multithreading • Task States • Task is typically an infinite loop than can be in any of five states • Dormant • Residing in memory but not available to the OS • Ready • Task is ready to execute but has a lower priority than the currently running task • Running • Task has control of the CPU • Waiting • Task requires the occurrence of an event (I/O operation to complete, shared resource available, etc.) • Interrupted • The task was running and an interrupt occurred—CPU is servicing the interrupt

7. Some Definitions (cont) • Context • Current Task’s CPU registers • Context Switch • Saving one task’s context and restoring another’s

8. Multiple Tasks

9. Task States

10. Kernel • Responsible for task management and inter-task communication • Kernel provides services to support context switching • Requires extra code space, additional data space, and additional task space • Requires additional CPU time

11. Scheduler (Dispatcher) • Responsible for determining which task will run next • Since most R-T Kernels are priority based, this is priority scheduler • Control of CPU is given to highest priority task that is ready to run • When task gets control of CPU is dependent upon type of Kernel used • Non-preemptive • Preemptive

12. Non-Preemptive Kernel • Requires task to explicitly give up control of the CPU • To maintain illusion of concurrency, this process must be done frequently • A`periodic tasks handled by ISR • ISR may make higher priority task ready to run but ISR always returns to interrupted task • Higher priority task gains control of CPU only when the current task relinquishes it

13. Preemptive Kernel • Highest priority task ready to run is always given control of the CPU • When a task makes a higher priority task ready to run, current task is preempted (suspended) and higher priority task given control of CPU • If ISR makes higher priority task ready, when ISR completes, the interrupted task is suspended and the higher priority task runs

14. Reentrancy • Reentrant Functions • A reentrant function may be used by more than one task without fear of data corruption • May be interrupted at any time and resumed later without loss of data • May use local or global variables • If using global variables, function must protect global data • Place arguments on task stack to preserve • Non-Reentrant Functions • Cannot guarantee integrity of data in multitasking system

15. Task Priority • Assigned to each task • Higher priorities given to most important tasks • Priority may be static or dynamic • Static Priority • Assigned at compile time • Doesn’t change during execution • Dynamic Priority • Assigned at run time • May be changed during run

16. Assigning Task Priorities • Alternatives • Static or fixed priority • Similar to what we did in the foreground/background approach (highest rate first) • Rate-Monotonic Algorithm • Highest Rate is given highest priority • Assumptions • Periodic tasks • Tasks do not synchronize with each other, share resources or exchange data • Preemptive scheduling must be used • RMS Theorem • Given n tasks, all task hard real-time deadlines will always be met if • (Ei/Ti) < n(21/n –1) , where Ei is maximum execution time of the task Ti is the execution period

17. RMS Theorem (cont) • If CPU utilization is less than 70% for all time critical tasks, we can meet all the required deadlines. • For design, a better approach is to design critical task load to use a maximum of approximately 50% of the CPU • This leaves some room the non-critical tasks and growth

18. Mutual Exclusion • Shared data structures provide easiest inter task communication scheme • Simplifies exchange of information • Must ensure each task exclusive access to data to avoid contention and corruption • Exclusive access methods • Disabling interrupts • Test and set operations • Disabling scheduling • Semaphores

19. Disabling and Enabling Interrupts • Shared resource access example pseudo code Disable interrupts; Access the resource (read/write from/to variables); Reenable interrupts; • OS may provide macros to support disabling and enabling interrupts • For Example, uC/OS-II macros • OS_ENTER_CRITICAL() • OS_EXIT_CRITICAL() • Caution: disabling interrupts for too long affects interrupt latency of system

20. Test-And-Set (TAS) • Define a global variable to be checked • To access a resource, function tests the global variable • If zero, function sets variable to one and begins using resource • If one, function knows the resource is in use and must wait to access it • Function using resource must clear the global variable when finished with the resource

21. Disabling and Enabling the Scheduler • Temporarily creates a non-preemptive situation • Interrupts are enabled but always return to the interrupted task independent of priority • Method works but probably should avoid • Defeats purpose of having a scheduler and a kernel

22. Semaphores • Used to • Control access to a shared resource (mutual exclusion) • Signal occurrence of an event • Allow two tasks to synchronize activities • Think of semaphore as a key that the code acquires in order to continue execution

23. Semaphores • Invented the Edgser Dijkstra in the 1960’s • Use to • control access to a shared resource (mutual exclusion) • signal the occurrence of an event • allow two tasks to synchronize their activities

24. Accessing Peripherals with Semaphores • Use binary semaphore

25. Buffer Management Using Semaphores • Counting Semaphore • Use when resource can be used by more than one task at same time • Example—10 buffers • Buffer manager satisfies first 10 buffer requests directly • When all semaphores used, task requesting buffer is suspended until semaphore available

26. Deadlocks and Semaphores • Situation where two tasks are waiting for resource held by the other • E.g. Task 1 has exclusive use of resource R1 and Task 2 has exclusive use of resource R2. • T1 requires exclusive use of R2 and T2 requires exclusive use of R1 • Neither task can complete • Avoid by • Acquire all resources before beginning • Acquire resources in same order • Release resource in reverse order • If kernel allows a timeout to be specified with semaphore (uC/OS-II does), this allows deadlock to be broken • Deadlocks generally occur in large, multi-tasking systems

27. Task Synchronization • Semaphores • Event Flags

28. Synchronization • Synchronize tasks with a semaphore • Will work with ISR or another task

29. Event Flags • Used to synchronize task with multiple event occurrence • Synchronize when any of the events have occurred • disjunctive synchronization • effectively the logical OR of event occurrence

30. Event Flags (Cont) • Synchronize when all of the events have occurred • conjunctive synchronization • effectively the logical AND of event occurrence

31. Multiple Task Signaling • Common events may signal multiple tasks