Real Time Operating Systems

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

2. Outline • Multitasking • tasks, kernels, context switching • Scheduling • types, priorities, interrupts, the “tick” • Resource Sharing (Mutual Exclusion) • reentrancy, techniques (semaphores), deadlock • Intertask Communication • queues and mailboxes 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 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) 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.. 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) Dr Alain Beaulieu

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

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

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 Dr Alain Beaulieu

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

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 Dr Alain Beaulieu

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

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 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 advantage: useful in avoiding priority inversion disadvantage: not easy to guarantee schedulability 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 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 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 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 Dr Alain Beaulieu

19. 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; } Reentrant Function Example 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 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( ): 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( ); 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 ? 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) 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

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} error message code Dr Alain Beaulieu

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) 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 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 1. Signal Task 2 4. wait for signal from task 1 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 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 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) 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 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] http://www.realtime-info.be/encyc/ market/rtos/rtos.htm Dr Alain Beaulieu