Multitasking has been around for decades, starting about when time-sharing IBM, Univac and CDC mainframes emerged. Timesharing enabled the computer to handle multiple “jobs” simultaneously, not in parallel or truly simultaneously, but overlapped so one could run while another one waited.
Back then, there were many significant periods of waiting to read data from a card reader or magnetic tape or output text to a printer or commands to a plotter. These were not real-time systems, but “batch” oriented services, designed for computing tasks such as mathematical computation, business operations, database information storage and retrieval.
Origins of Embedded Multitasking
Around the same time, embedded systems were emerging, mainly for military applications, that required real-time operating systems (RTOS) or “executives.” These systems could respond to real-time events and handle other tasks in the background while waiting for the next event. These early RTOSes employed foreground/background architectures, where the background was controlled by a “Big Loop” type of sequential scheduler and the foreground was a glorified ISR.
The Big Loop Scheduler became a problem. As applications grew, the loop expanded and responsiveness declined. Multitasking offered a mixed mode of adjusted background scheduling, where real-time events could influence the scheduling of background tasks.
Tasks would run until they were blocked or until a time limit expired, then while they wait for their next turn or until what they were blocked by was no longer there, and other tasks were allowed to run. This way, multiple tasks were active at any point in time, but at various stages of their code, with only one actually executing instructions while the others waited their turn.
Multitasking proved to be a lot more efficient than the Big Loop, and became the backbone of all modern RTOS architecture and even multithreading hardware schedulers like those found in MIPS and Intel processors. This topic was explored by Bill Lamie in 1997 in “Multitasking Mysteries,” in Embedded Systems Programming and on Embedded.com.
Multitasking: Even more critical today
Technology and market trends in embedded computing have driven the need for RTOS control to an even greater extent. Larger memory, faster processors, smaller packaging, and the pervasiveness of networking, USB and graphics have changed the landscape of embedded systems and created increased demand for RTOSes.
As Bill notes in “What is an RTOS and why use one,” an RTOS is not always needed However, as the price point of 32-bit processors with more than 64KB of memory has dropped, more applications have taken advantage of the opportunity to add functionality in an effort to get ahead of their competition. As systems become more complex, there is more need for an RTOS to help developers control application services in real time.
Despite the many capabilities and services of an RTOS, some developers fear using them because of what they feel is the addition of unnecessary overhead. It turns out that in most cases, the RTOS can actually reduce overhead through its more efficient scheduling algorithms compared to the use of a Big Loop method as is typically done in non-RTOS applications.
Given the increased relevance and importance of an RTOS in today’s embedded systems, it makes sense to revisit Bill Lamie’s article to recall multithreading fundamentals to see if your next project might benefit from an RTOS.
Today’s advanced 32-bit processor architectures are being used in real-time applications in all sorts of fields, yet the same issues of multitasking that we began to address in the 50’s and 60’s still require attention.
An RTOS is a great way to use a multitasking scheduler to assist in efficiently managing an application that can be structured as cooperating semi-autonomous elements. Call these elements “tasks” or “threads,” they are staples of modern real-time software and their care and feeding are critical to the ultimate success of the system.
For further reading:
Embedded.com Collection – Building blocks: the RTOS
Measure your RTOS's real-time performance
Effective use of RTOS programming concepts to support advanced multithreaded architectures
Multitasking with Multiple Processors
Lower the overhead in RTOS scheduling
Multitasking alternatives and the perils of preemption
John A. Carbone , vice president of marketing for Express Logic, has 35 years’ experience in real-time computer systems and software, ranging from embedded system developer and FAE to vice president of sales and marketing. He has a BS degree in mathematics from Boston College.