BY PHILIP KOOPMAN JR . o most embedded develop­ ers, multitasking means using a preemptive multi­ tasker and a complex, ex­ Cooperative pensive (in terms of soft­ wareT cost, memory size, and run-time tasking overhead) piece of software. While em­ bedded real-time systems are best writ­ techniques can ten with a multitasking approach, pre­ emptive multitasking is often overkill. often meet an A preemptive multitasker is a very gen­ eralized tool; users may not want to pay embedded the costs that always accompany gener­ alized solutions to their very specific system's problems. A less widely understood approach multitasking to real-time design is cooperative multi­ tasking. Judicious use of cooperative requirements and tasking techniques can often meet an embedded system's multitasking re­ give better quirements, while giving better perfor­ mance and a simpler software environ­ performance. ment than a preemptive multitasker. In my work with stack-based proces­ sors at Harris Semiconductor Inc., I've Tasks can also be used to distinguish investigated the different approaches to different activity classes for a system. multitasking and explored the different For example, routines that only need to tradeoffs among complexity, cost, and be invoked occasionally can be included speed. As a result, I'm convinced that in a task run in response to an external the ease of implementation and effi­ stimulus, such as an interrupt or a timer ciency of cooperative multitasking are pulse. Tasks that always run but are not widely underestimated. time-critical can be assigned lower priorities than other tasks. WHY MULmASKING? On larger systems with multiple pro­ ultitasking is used in embed­ cessors, breaking a software system into ded systems for a variety of tasks provides natural boundaries for M purposes. Keeping separate process migration. Setting parallelism system functions resident in separate granularity at the task level allows each tasks helps reduce the complexity of processor to be assigned to one or more each portion of the system. Separate active tasks, greatly reducing the soft­ tasks also help modularize the work of ware's complexity. In the best of all pos­ writing the system by forcing the cre­ sible worlds, we have one processor per ation of well-defined interfaces between task. Unfortunately, not all systems modules and programmers. have the luxury of multiple processors. APRIL 1990 EMBEDDED SYSTEMS PROGRAMMING 43 Hemyweight Tasking The problem comes when many tasks The preemptive method is usually contend for use of a single processor. what is meant by "multitasking" in con­ This processor must be shared among ventional computing terminology. In a tasks, which can involve significant preemptive multitasker, some prede­ overhead. fined event, such as a timer pulse, peri­ odically halts the executing program PREEMPTIVE TASKING and transfers control to an executive orth has a long tradition of pro­ program or kernel. The kernel saves the viding many support levels for complete state of the processor (all reg­ F multitasking. While coopera­ isters and status bits), including the pro­ tive multitasking is a well-known tech­ gram counter and stack contents. Once nique in Forth circles, the technique the old task state is saved, the kernel needn't be limited to that language. In­ uses some scheme to select another task deed, with the recent appearance of C for execution. The newly selected task compilers for stack processors like the has its state loaded into the processor RTX, the approach becomes particu­ and execution is resumed on the new larly attractive for C programmers as task. well. However, stack processors do alter The advantage to full preemptive some of the design tradeoffs. multitasking is that it is almost trans- Table 1 Pause subroutine code for a lightweight multltasller written for the RTX 2000 RTX 2000 Instruction Comment R> Transfer return address of calling task (task restart address) to data stack. OUI Store that restart address to task area word 0. 1 UO Fetch link value from task area word I. UBRI Store that link value as the new value of the user base register. ouo Fetch the restart address of the new task from the new task area. >R EXIT Transfer the restart address from the data stack to the return stack, then perform a subroutine return (equivalent to a jump to the restart address). felbns I. Each task uses the user base register to point to a 32-word task area used for scratch storage. 2. The pause subroutine code takes six words of memory shared among all tasks. 3. Each invocation of pause code takes I0 clock cycles, including the subroutine call instruc­ tion from the calling task. 44EMBEDDEDSYSTEMSPllOGRAMMIN6 APRIL 1990 parent to the programmer, and it is a powerful and automatic way to ensure that no problems occur during the tran­ sitions between tasks. Unfortunately, the oost for this transparency and power is very high. The machine's entire state must be saved to guarantee a correct restart when the task is resumed. In contrast to RISC and most ClSC processors, however, most stack ma­ chines automatically track the number of active elements on the stack. Tn prac­ tice, the stacks tend to be fairly shallow. However, whatever processor architec­ ture you 're using, the oost for a preemp­ tive multitasker context switch is high. An additional problem with preemp­ tive multitasking is that certain code se­ quences, known as critical regions, must not be interrupted by a task switch. Typically, these sequences deal with ac­ cess to resources shared among tasks or time-critical code. To prevent a preemptive multitasker from interrupting these sequences, a flag must be used to notify the executive that the task is in a critical region. Be­ cause task switches are forbidden with­ in these regions, task-switching latency increases dramatically. Alternatively, semaphores or other synchronization methods may be used to notify other tasks when a data structure is in use in case the task is interrupted. Either way, a considerable run-time overhead and programming effort is involved in pre­ venting a preemption from causing problems. HEAVYWEIGHT COOPERATION n some systems, the number of shared data references and critical I regions executed will have a much greater impact on efficiency than the number of task switches made. Or, you may be dealing with a relatively simple system where it's hard to justify the generality and complexity of a preemp­ tive multitasker. In these cases, it may APR LL L990 EMBEDDED SYSTEMS PROGRAMMING 45 actually be desirable to do away with tive tasking method is that neither syn­ the preemptive tasker and implement chronization variables nor critical-re­ Hearyweight cooperative tasking. gion flags are necessary. Since task In cooperative tasking, the task de­ switching only occurs when the pro­ cides when it is ready to give up control grammer requires it, a task cannot be Tasking of the processor. This decision is typical­ shut down by the kernel at an inoppor­ ly made by each task. The task periodi­ tune moment. This fact can substantial­ cally invokes a routine that queries a ly reduce your run-time overhead and timer to see whether the system desires code complexity. Further, much of the a task switch. This technique is called code in the kernel used for synchroniza­ "pausing." tion and data-structure sharing can be In a simplified but oft-used case, a eliminated, reducing memory costs. In cooperative task switch is performed on every pause. The disadvantage of using the coop­ When it is time for a task switch, the full erative tasking method is that it places tasking, the task processor state is saved in a manner more of a burden on the programmer similar to that used for preemptive task­ for correct operation. Programmers are decides when it is ing. The term "heavyweight" is used be­ responsible for ensuring that periodic cause the complete machine state must checks for task switching are placed in completed and be saved to guarantee correct operation. appropriate sections of the code. If they The term "cooperative" is used because place these checks wisely, the result will ready to give up the task relinquishes control of the sys­ be good performance with small task­ tem by executing pause statements switcbing latencies. Ifprogrammers are control of the sprinkled throughout its code rather not so wise, some task-switching laten­ than relyi ng on an external preemption cies may be undesirably long. processor to other mechanism. The advantage to using the coopera- DEALING WITH LATENCY tasks. he issue of task-switching laten­ cy can be addressed in three T ways. First, we can use coopera­ tive tasking in applications where task­ Figure 1 switcbing latency is not extremely criti­ Characteristics of tasking models. cal or the tasks are quite simple and rely ... • No pauses used, timer-driven on the programmer's skills. Obviously Low High scheduler preempts programs this approach has limited applicability. Preemptive anywhere The second way to reduce this prob­ multitasker • Critical regions and lem is to move all time-critical code to synchronization required for correct operation interrupt-service routines. For example, a task that is activated to read data from an input port before the data is overrun Heavyweight • Pause anywhere • Same context switching cost can be replaced by an interrupt-service cooperative as preemptive multitasker routine that places the data into a first­ multitasker • Cooperati ve model reduces in-first-out buffer and a task that pro­ need for synchronization cesses data from that buffer. This strat­ egy has the effect of desensitizing the System Transparency • Pause at module boundaries, Medium-weight system to task-switching latency. Simi­ efficiency to programmer when stacks are small cooperative • Programmer sched ules pauses lar methods must often be used with muJtitasker for reduced context switching preemptive tasking models as well be­ costs cause of their problems with latency • Cooperative model reduces caused by the critical regions.