Definition of Multitasking 1. Running number of programs simultaneously: the simultaneous management of two or more tasks by a computer or a person 2. Differences between computers and humans a. Information bandwidth b. Speed of recall c. Leaky recall (forgetfulness as opposed to memory reuse) Myth! Myth? 3. Multitasking == Selective attention == Distraction == Inattention a. In 2005, the BBC reported on a research study, funded by Hewlett-Packard and conducted by the Institute of Psychiatry at the University of London, that found, "Workers distracted by e-mail and phone calls suffer a fall in IQ more than twice that found in marijuana smokers." (http://www.sundayobserver.lk/2012/08/19/spe11.asp) 4. Cost of multitasking a. Time to switch context b. memory to archive context c. effort to prioritize tasks 5. Conditions required for multitasking a. Time with nothing to do (no pending tasks) b. Tasks that can tolerate infinite delay c. Tasks that can be offloaded d. No conflict for resources e. 6. Reading assignments a. Basics of embedded multitasking Part 1 b. Basics of embedded multi tasking Part 2 1
c. Basics of embedded multi tasking Part 3 7. Links a. http://www.nea.org/home/30584.htm b. http://theoryofconstraints.blogspot.com/2007/07/multi-tasking-why-projects-take-solong.html c. http://www.freertos.org Introduction to Multitasking RTOS Fundamentals http://www.freertos.org/implementation/index.html?http://www.freertos.org/implementation/a00002.html The kernel is the core component within an operating system. Operating systems such as Linux employ kernels that allow users access to the computer seemingly simultaneously. Multiple users can execute multiple programs apparently concurrently. Each executing program is a task under control of the operating system. If an operating system can execute multiple tasks in this manner it is said to be multitasking. The use of a multitasking operating system can simplify the design of what would otherwise be a complex software application: The multitasking and inter-task communications features of the operating system allow the complex application to be partitioned into a set of smaller and more manageable tasks. The partitioning can result in easier software testing, work breakdown within teams, and code reuse. Complex timing and sequencing details can be removed from the application code and become the responsibility of the operating system. Multitasking Vs Concurrency A conventional processor can only execute a single task at a time - but by rapidly switching between tasks a multitasking operating system can make it appear as if each task is executing concurrently. This is depicted by the diagram below which shows the execution pattern of three tasks with respect to time. The task names are color coded and written down the left hand. Time moves from left to right, with the colored lines showing which task is executing at any particular time. The upper diagram demonstrates the perceived concurrent execution pattern, and the lower the actual multitasking execution pattern. 2
3
Figure 1. RTOS Simplified Control Flow Diagram Scheduling [1.RTOS Fundamentals http://www.freertos.org/implementation/index.html?http://www.freertos.org/implementation/a00002.html] The scheduler is the part of the kernel responsible for deciding which task should be executing at any particular time. The kernel can suspend and later resume a task many times during the task lifetime. The scheduling policy is the algorithm used by the scheduler to decide which task to execute at any point in time. The policy of a (non real time) multi user system will most likely allow each task a "fair" proportion of processor time. The policy used in real time / embedded systems is described later. In addition to being suspended involuntarily by the RTOS kernel a task can choose to suspend itself. It will do this if it either wants to delay (sleep) for a fixed period, or wait (block) for a resource to become available (eg a serial port) or an event to occur (eg a key press). A blocked or sleeping task is not able to execute, and will not be allocated any processing time. 4
Referring to the numbers in the diagram above: At (1) task 1 is executing. At (2) the kernel suspends task 1...... and at (3) resumes task 2. While task 2 is executing (4), it locks a processor peripheral for its own exclusive access. At (5) the kernel suspends task 2...... and at (6) resumes task 3. Task 3 tries to access the same processor peripheral, finding it locked task 3 cannot continue so suspends itself at (7). At (8) the kernel resumes task 1. Etc. The next time task 2 is executing (9) it finishes with the processor peripheral and unlocks it. The next time task 3 is executing (10) it finds it can now access the processor peripheral and this time executes until suspended by the kernel. Listing 1. Programming model of a periodic task void task_example(void) /* Declaration of task dynamic variables */ /* Initialization of task variables */ (...) task_init(); /* task_create() executes the task code up to the end of the task_init() system call, thus the actual periodic execution starts from here */ while(1) /* Code of each periodic instance */ (...) end_cycle(); 5
Figure 2. Three possible task execution states Context Switching [1.RTOS Fundamentals http://www.freertos.org/implementation/index.html?http://www.freertos.org/implementation/a00002.html] As a task executes it utilizes the processor / microcontroller registers and accesses RAM and ROM just as any other program. These resources together (the processor registers, stack, etc.) comprise the task execution context. A task is a sequential piece of code - it does not know when it is going to get suspended or resumed by the kernel and does not even know when this has happened. Consider the example of a task being suspended immediately before executing an instruction that sums the values contained within two processor registers. 6
While the task is suspended other tasks will execute and may modify the processor register values. Upon resumption the task will not know that the processor registers have been altered - if it used the modified values the summation would result in an incorrect value. To prevent this type of error it is essential that upon resumption a task has a context identical to that immediately prior to its suspension. The operating system kernel is responsible for ensuring this is the case - and does so by saving the context of a task as it is suspended. When the task is resumed its saved context is restored by the operating system kernel prior to its execution. The process of saving the context of a task being suspended and restoring the context of a task being resumed is called context switching. Real Time Applications [1.RTOS Fundamentals http://www.freertos.org/implementation/index.html?http://www.freertos.org/implementation/a00002.html] Real time operating systems (RTOS's) achieve multitasking using these same principals - but their objectives are very different to those of non real time systems. The different objective is reflected in the scheduling policy. Real time / embedded systems are designed to provide a timely response to real world events. Events occurring in the real world can have deadlines before which the real time / embedded system must respond and the RTOS scheduling policy must ensure these deadlines are met. To achieve this objective the software engineer must first assign a priority to each task. The scheduling policy of the RTOS is then to simply ensure that the highest priority task that is able to execute is the task given processing time. This may require sharing processing time "fairly" between tasks of equal priority if they are ready to run simultaneously. 7
Example: The most basic example of this is a real time system that incorporates a keypad and LCD. A user must get visual feedback of each key press within a reasonable period - if the user cannot see that the key press has been accepted within this period the software product will at best be awkward to use. If the longest acceptable period was 100ms - any response between 0 and 100ms would be acceptable. This functionality could be implemented as an autonomous task with the following structure: void vkeyhandlertask( void *pvparameters ) // Key handling is a continuous process and as such the task // is implemented using an infinite loop (as most real time // tasks are). for( ;; ) [Suspend waiting for a key press] [Process the key press] Now assume the real time system is also performing a control function that relies on a digitally filtered input. The input must be sampled, filtered and the control cycle executed every 2ms. For correct operation of the filter the temporal regularity of the sample must be accurate to 0.5ms. This functionality could be implemented as an autonomous task with the following structure: void vcontroltask( void *pvparameters ) for( ;; ) [Suspend waiting for 2ms since the start of the previous cycle] [Sample the input] [Filter the sampled input] [Perform control algorithm] [Output result] The software engineer must assign the control task the highest priority as: 1. The deadline for the control task is stricter than that of the key handling task. 2. The consequence of a missed deadline is greater for the control task than for the key handler task. The next page demonstrates how these tasks would be scheduled by a real time operating system. Real Time Scheduling [1.RTOS Fundamentals http://www.freertos.org/implementation/index.html?http://www.freertos.org/implementation/a00002.html] The diagram below demonstrates how the tasks defined on the previous page would be scheduled by a real time operating system. The RTOS has itself created a task - the idle task - which will execute only when there are no other tasks able to do so. The RTOS idle task is always in a state where it is able to 8
execute. Referring to the diagram above: At the start neither of our two tasks are able to run - vcontroltask is waiting for the correct time to start a new control cycle and vkeyhandlertask is waiting for a key to be pressed. Processor time is given to the RTOS idle task. At time t1, a key press occurs. vkeyhandlertask is now able to execute - it has a higher priority than the RTOS idle task so is given processor time. At time t2 vkeyhandlertask has completed processing the key and updating the LCD. It cannot continue until another key has been pressed so suspends itself and the RTOS idle task is again resumed. At time t3 a timer event indicates that it is time to perform the next control cycle. vcontroltask can now execute and as the highest priority task is scheduled processor time immediately. Between time t3 and t4, while vcontroltask is still executing, a key press occurs. vkeyhandlertask is now able to execute, but as it has a lower priority than vcontroltask it is not scheduled any processor time. At t4 vcontroltask completes processing the control cycle and cannot restart until the next timer event - it suspends itself. vkeyhandlertask is now the task with the highest priority that is able to run so is scheduled processor time in order to process the previous key press. At t5 the key press has been processed, and vkeyhandlertask suspends itself to wait for the next key event. Again neither of our tasks are able to execute and the RTOS idle task is scheduled processor time. Between t5 and t6 a timer event is processed, but no further key presses occur. The next key press occurs at time t6, but before vkeyhandlertask has completed processing the key a timer event occurs. Now both tasks are able to execute. As vcontroltask has the higher priority vkeyhandlertask is suspended before it has completed processing the key, and vcontroltask is scheduled processor time. At t8 vcontroltask completes processing the control cycle and suspends itself to wait for the next. vkeyhandlertask is again the highest priority task that is able to run so is scheduled processor time so the key press processing can be completed. The RTOS Tick [RTOS Implementation Building Blocks] 9
When sleeping, a task will specify a time after which it requires 'waking'. When blocking, a task can specify a maximum time it wishes to wait. The FreeRTOS real time kernel measures time using a tick count variable. A timer interrupt (the RTOS tick interrupt) increments the tick count with strict temporal accuracy - allowing the real time kernel to measure time to a resolution of the chosen timer interrupt frequency. Each time the tick count is incremented the real time kernel must check to see if it is now time to unblock or wake a task. It is possible that a task woken or unblocked during the tick ISR will have a priority higher than that of the interrupted task. If this is the case the tick ISR should return to the newly woken/unblocked task - effectively interrupting one task but returning to another. This is depicted below: Referring to the numbers in the diagram above: At (1) the RTOS idle task is executing. At (2) the RTOS tick occurs, and control transfers to the tick ISR (3). The RTOS tick ISR makes vcontroltask ready to run, and as vcontroltask has a higher priority than the RTOS idle task, switches the context to that of vcontroltask. As the execution context is now that of vcontroltask, exiting the ISR (4) returns control to vcontroltask, which starts executing (5). A context switch occurring in this way is said to be Preemptive, as the interrupted task is preempted without suspending itself voluntarily. 10