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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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”

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

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

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

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

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

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

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

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 fault tolerance - features which enable a system to continue functioning even in the presence of faults. 24-Apr-17 Dr Alain Beaulieu