Processes and Operating Systems

Transcription

1 CHAPTER Processes and Operating Systems The process abstraction. Switching contexts between programs. Real-time operating systems (RTOSs). Interprocess communication. Task-level performance analysis and power consumption. A telephone answering machine design. 6 INTRODUCTION Although simple applications can be programmed on a microprocessor by writing a single piece of code, many applications are sophisticated enough that writing one large program does not suffice. When multiple operations must be performed at widely varying times,a single program can easily become too complex and unwieldy. The result is spaghetti code that is too difficult to verify for either performance or functionality. This chapter studies the two fundamental abstractions that allow us to build complex applications on microprocessors: the process and the operating system (OS). Together, these two abstractions let us switch the state of the processor between multiple tasks. The process cleanly defines the state of an executing program, while the OS provides the mechanism for switching execution between the processes. These two mechanisms together let us build applications with more complex functionality and much greater flexibility to satisfy timing requirements. The need to satisfy complex timing requirements events happening at very different rates, intermittent events,and so on causes us to use processes and OSs to build embedded software. Satisfying complex timing tasks can introduce extremely complex control into programs. Using processes to compartmentalize functions and encapsulating in the OS the control required to switch between processes make it much easier to satisfy timing requirements with relatively clean control within the processes. 293

2 294 CHAPTER 6 Processes and Operating Systems We are particularly interested in real-time operating systems (RTOSs),which are OSs that provide facilities for satisfying real-time requirements. A RTOS allocates resources using algorithms that take real time into account. General-purpose OSs, in contrast, generally allocate resources using other criteria like fairness. Trying to allocate the CPU equally to all processes without regard to time can easily cause processes to miss their deadlines. In the next section, we will introduce the concepts of task and process. Section 6.2 looks at how the RTOS implements processes. Section 6.3 develops algorithms for scheduling those processes to meet real-time requirements. Section 6.4 introduces some basic concepts in interprocess communication. Section 6.5 considers the performance of RTOSs while Section 6.6 looks at power consumption. Section 6.7 walks through the design of a telephone answering machine. 6.1 MULTIPLE TASKS AND MULTIPLE PROCESSES Most embedded systems require functionality and timing that is too complex to embody in a single program. We break the system into multiple tasks in order to manage when things happen. In this section we will develop the basic abstractions that will be manipulated by the RTOS to build multirate systems Tasks and Processes Many (if not most) embedded computing systems do more than one thing that is, the environment can cause mode changes that in turn cause the embedded system to behave quite differently. For example, when designing a telephone answering machine, we can define recording a phone call and operating the user s control panel as distinct tasks, because they perform logically distinct operations and they must be performed at very different rates. These different tasks are part of the system s functionality,but that application-level organization of functionality is often reflected in the structure of the program as well. A process is a single execution of a program. If we run the same program two different times, we have created two different processes. Each process has its own state that includes not only its registers but all of its memory. In some OSs, the memory management unit is used to keep each process in a separate address space. In others, particularly lightweight RTOSs, the processes run in the same address space. Processes that share the same address space are often called threads. In this book, we will use the terms tasks and processes somewhat interchangeably, as do many people in the field. To be more precise, task can be composed of several processes or threads;it is also true that a task is primarily an implementation concept and process more of an implementation concept.

3 6.1 Multiple Tasks and Multiple Processes 295 To understand why the separation of an application into tasks may be reflected in the program structure, consider how we would build a stand-alone compression unit based on the compression algorithm we implemented in Section 3.7. As shown in Figure 6.1,this device is connected to serial ports on both ends.the input to the box is an uncompressed stream of bytes.the box emits a compressed string of bits on the output serial line,based on a predefined compression table. Such a box may be used, for example, to compress data being sent to a modem. The program s need to receive and send data at different rates for example, the program may emit 2 bits for the first byte and then 7 bits for the second byte will obviously find itself reflected in the structure of the code. It is easy to create irregular, ungainly code to solve this problem; a more elegant solution is to create a queue of output bits, with those bits being removed from the queue and sent to the serial port in 8-bit sets. But beyond the need to create a clean data structure that simplifies the control structure of the code,we must also ensure that we process the inputs and outputs at the proper rates. For example, if we spend too much time in packaging and emitting output characters,we may drop an input character. Solving timing problems is a more challenging problem. Uncompressed data Serial line Serial line Compressed Compressor data Character Compresssor Bit queue Compression table FIGURE 6.1 An on-the-fly compression box.

4 296 CHAPTER 6 Processes and Operating Systems The text compression box provides a simple example of rate control problems. A control panel on a machine provides an example of a different type of rate control problem,the asynchronous input.the control panel of the compression box may, for example, include a compression mode button that disables or enables compression, so that the input text is passed through unchanged when compression is disabled. We certainly do not know when the user will push the compression mode button the button may be depressed asynchronously relative to the arrival of characters for compression. We do know, however, that the button will be depressed at a much lower rate than characters will be received, since it is not physically possible for a person to repeatedly depress a button at even slow serial line rates. Keeping up with the input and output data while checking on the button can introduce some very complex control code into the program. Sampling the button s state too slowly can cause the machine to miss a button depression entirely, but sampling it too frequently and duplicating a data value can cause the machine to incorrectly compress data. One solution is to introduce a counter into the main compression loop, so that a subroutine to check the input button is called once every n times the compression loop is executed. But this solution does not work when either the compression loop or the button-handling routine has highly variable execution times if the execution time of either varies significantly, it will cause the other to execute later than expected, possibly causing data to be lost. We need to be able to keep track of these two different tasks separately, applying different timing requirements to each. This is the sort of control that processes allow. The above two examples illustrate how requirements on timing and execution rate can create major problems in programming. When code is written to satisfy several different timing requirements at once, the control structures necessary to get any sort of solution become very complex very quickly. Worse, such complex control is usually quite difficult to verify for either functional or timing properties Multirate Systems Implementing code that satisfies timing requirements is even more complex when multiple rates of computation must be handled. Multirate embedded computing systems are very common,including automobile engines,printers,and cell phones. In all these systems,certain operations must be executed periodically,and each operation is executed at its own rate.application Example 6.1 describes why automobile engines require multirate control. Application Example 6.1 Automotive engine control The simplest automotive engine controllers, such as the ignition controller for a basic motorcycle engine, perform only one task timing the firing of the spark plug, which takes the place

5 6.1 Multiple Tasks and Multiple Processes 297 of a mechanical distributor. The spark plug must be fired at a certain point in the combustion cycle, but to obtain better performance, the phase relationship between the piston s movement and the spark should change as a function of engine speed. Using a microcontroller that senses the engine crankshaft position allows the spark timing to vary with engine speed. Firing the spark plug is a periodic process (but note that the period depends on the engine s operating speed). Spark plug Engine controller Crankshaft position The control algorithm for a modern automobile engine is much more complex, making the need for microprocessors that much greater. Automobile engines must meet strict requirements (mandated by law in the United States) on both emissions and fuel economy. On the other hand, the engines must still satisfy customers not only in terms of performance but also in terms of ease of starting in extreme cold and heat, low maintenance, and so on. Automobile engine controllers use additional sensors, including the gas pedal position and an oxygen sensor used to control emissions. They also use a multimode control scheme. For example, one mode may be used for engine warm-up, another for cruise, and yet another for climbing steep hills, and so forth. The larger number of sensors and modes increases the number of discrete tasks that must be performed. The highest-rate task is still firing the spark plugs. The throttle setting must be sampled and acted upon regularly, although not as frequently as the crankshaft setting and the spark plugs. The oxygen sensor responds much more slowly than the throttle, so adjustments to the fuel/air mixture suggested by the oxygen sensor can be computed at a much lower rate. The engine controller takes a variety of inputs that determine the state of the engine. It then controls two basic engine parameters: the spark plug firings and the fuel/air mixture. The engine control is computed periodically, but the periods of the different inputs and outputs range over several orders of magnitude of time. An early paper on automotive electronics by Marley [Mar78] described the rates at which engine inputs and outputs must be handled.

6 298 CHAPTER 6 Processes and Operating Systems Variable Time to move full range (ms) Update period (ms) Engine spark timing Throttle 40 2 Airflow 30 4 Battery voltage 80 4 Fuel flow Recycled exhaust gas Set of status switches Air temperature seconds 500 Barometric pressure seconds 1000 Spark/dwell 10 1 Fuel adjustments 80 4 Carburetor adjustments Mode actuators Timing Requirements on Processes Processes can have several different types of timing requirements imposed on them by the application.the timing requirements on a set of processes strongly influence the type of scheduling that is appropriate.a scheduling policy must define the timing requirements that it uses to determine whether a schedule is valid. Before studying scheduling proper, we outline the types of process timing requirements that are useful in embedded system design. Figure 6.2 illustrates different ways in which we can define two important requirements on processes: release time and deadline. The release time is the time at which the process becomes ready to execute; this is not necessarily the time at which it actually takes control of the CPU and starts to run. An aperiodic process is by definition initiated by an event, such as external data arriving or data computed by another process. The release time is generally measured from that event, although the system may want to make the process ready at some interval after the event itself. For a periodically executed process, there are two common possibilities. In simpler systems, the process may become ready at the beginning of the period. More sophisticated systems, such as those with data dependencies between processes, may set the release time at the arrival time of certain data, at a time after the start of the period. A deadline specifies when a computation must be finished. The deadline for an aperiodic process is generally measured from the release time, since that is the only reasonable time reference. The deadline for a periodic process may in general occur at some time other than the end of the period. As seen in Section 6.3.1,some scheduling policies make the simplifying assumption that the deadline occurs at the end of the period.

7 6.1 Multiple Tasks and Multiple Processes 299 Deadline P1 Release time Aperiodic process Time Deadline P1 Release time Time Period Periodic process initiated at start of period Deadline P1 Release time Time Period Periodic process released by event FIGURE 6.2 Example definitions of release times and deadlines. Rate requirements are also fairly common. A rate requirement specifies how quickly processes must be initiated. The period of a process is the time between successive executions. For example, the period of a digital filter is defined by the time interval between successive input samples. The process s rate is the inverse of its period. In a multirate system, each process executes at its own distinct rate. The most common case for periodic processes is for the initiation interval to be equal to the period. However, pipelined execution of processes allows the initiation interval to be less than the period. Figure 6.3 illustrates process execution in a system with four CPUs.The various execution instances of program P1 have been subscripted to distinguish their initiation times. In this case, the initiation interval is equal to onefourth of the period. It is possible for a process to have an initiation rate less than the period even in single-cpu systems. If the process execution time is significantly less than the period, it may be possible to initiate multiple copies of a program at slightly offset times.

8 300 CHAPTER 6 Processes and Operating Systems CPU 1 P1 i P1 i 1 4 CPU 2 P1 i 1 1 P1 i 1 5 CPU 3 P1 i 1 2 P1 i 1 6 CPU 4 P1 i 1 3 P1 i 1 7 Time FIGURE 6.3 A sequence of processes with a high initiation rate. What happens when a process misses a deadline? The practical effects of a timing violation depend on the application the results can be catastrophic in an automotive control system,whereas a missed deadline in a multimedia system may cause an audio or video glitch. The system can be designed to take a variety of actions when a deadline is missed. Safety-critical systems may try to take compensatory measures such as approximating data or switching into a special safety mode. Systems for which safety is not as important may take simple measures to avoid propagating bad data, such as inserting silence in a phone line, or may completely ignore the failure. Even if the modules are functionally correct, their timing improper behavior can introduce major execution errors. Application Example 6.2 describes a timing problem in space shuttle software that caused the delay of the first launch of the shuttle. Application Example 6.2 A space shuttle software error Garman [Gar81] describes a software problem that delayed the first launch of the U.S. space shuttle. No one was hurt and the launch proceeded after the computers were reset. However, this bug was serious and unanticipated. The shuttle s primary control system was known as the Primary Avionics Software System (PASS). It used four computers to monitor events, with the four machines voting to ensure fault tolerance. Four computers allowed one machine to fail while still leaving three operating machines to vote, such that a majority vote would still be possible to determine operating procedures. If at least two machines failed, control was to be turned over to a fifth computer called the Backup Flight Control System (BFS). The BFS used the same computer, requirements, programming language, and compiler, but it was developed by a different organization than the one that built the PASS to ensure that methodological errors did not cause simultaneous failure of both systems. The switchover from PASS to BFS was controlled by the astronauts.

9 6.1 Multiple Tasks and Multiple Processes 301 During normal operation, the BFS would listen to the operation of the PASS computers so that it could keep track of the state of the shuttle. However, BFS would stop listening when it thought that PASS was compromising data fetching. This would prevent PASS failures from inadvertently destroying the state of the BFS. PASS used an asynchronous, priority-driven software architecture. If high-priority processes take too much time, the OS can skip or delay lower-priority processing. The BFS, in contrast, used a time-slot system that allocated a fixed amount of time to each process. Since the BFS monitored the PASS, it could get confused by temporary overloads on the primary system. As a result, the PASS was changed late in the design cycle to make its behavior more amenable to the backup system. On the morning of the launch attempt, the BFS failed to synchronize itself with the primary system. It saw the events on the PASS system as inconsistent and therefore stopped listening to PASS behavior. It turned out that all PASS and BFS processing had been running late relative to telemetry data. This occurred because the system incorrectly calculated its start time. After much analysis of system traces and software, it was determined that a few minor changes to the software had caused the problem. First, about 2 years before the incident, a subroutine used to initialize the data bus was modified. Since this routine was run prior to calculating the start time, it introduced an additional, unnoticed delay into that computation. About a year later, a constant was changed in an attempt to fix that problem. As a result of these changes, there was a 1 in 67 probability for a timing problem. When this occurred, almost all computations on the computers would occur a cycle late, leading to the observed failure. The problems were difficult to detect in testing since they required running through all the initialization code; many tests start with a known configuration to save the time required to run the setup code. The changes to the programs were also not obviously related to the final changes in timing. The order of execution of processes may be constrained when the processes pass data between each other. Figure 6.4 shows a set of processes with data dependencies among them. Before a process can become ready,all the processes on which it depends must complete and send their data to it. The data dependencies define a partial ordering on process execution P1 and P2 can execute in any order (or in interleaved fashion) but must both complete before P3, and P3 must complete before P4.All processes must finish before the end of the period.the data dependencies must form a directed acyclic graph (DAG) a cycle in the data dependencies is difficult to interpret in a periodically executed system. A set of processes with data dependencies is known as a task graph. Although the terminology for elements of a task graph varies from author to author, we will consider a component of the task graph (a set of nodes connected by data dependencies) as a task and the complete graph as the task set. Figure 6.4 also shows a second task with two processes. The two tasks ({P1, P2, P3, P4} and {P5, P6}) have no timing relationships between them. Communication among processes that run at different rates cannot be represented by data dependencies because there is no one-to-one relationship between data coming out of the source process and going into the destination process.

10 302 CHAPTER 6 Processes and Operating Systems P1 P2 P5 P3 P4 P6 FIGURE 6.4 Data dependencies among processes. System Video Audio FIGURE 6.5 Communication among processes at different rates. Nevertheless, communication among processes of different rates is very common. Figure 6.5 illustrates the communication required among three elements of an MPEG audio/video decoder. Data come into the decoder in the system format, which multiplexes audio and video data. The system decoder process demultiplexes the audio and video data and distributes it to the appropriate processes. Multirate communication is necessarily one way for example, the system process writes data to the video process, but a separate communication mechanism must be provided for communication from the video process back to the system process CPU Metrics We also need some terminology to describe how the process actually executes.the initiation time is the time at which a process actually starts executing on the CPU. The completion time is the time at which the process finishes its work. The most basic measure of work is the amount of CPU time expended by a process. The CPU time of process i is called C i. Note that the CPU time is not equal to the completion time minus initiation time; several other processes may interrupt execution. The total CPU time consumed by a set of processes is

11 6.1 Multiple Tasks and Multiple Processes 303 T T i. (6.1) 1 i n We need a basic measure of the efficiency with which we use the CPU. The simplest and most direct measure is utilization: U CPU time for useful work total available CPU time. (6.2) Utilization is the ratio of the CPU time that is being used for useful computations to the total available CPU time. This ratio ranges between 0 and 1, with 1 meaning that all of the available CPU time is being used for system purposes. The utilization is often expressed as a percentage. If we measure the total execution time of all processes over an interval of time t, then the CPU utilization is U T t. (6.3) Process State and Scheduling The first job of the OS is to determine that process runs next.the work of choosing the order of running processes is known as scheduling. The OS considers a process to be in one of three basic scheduling states: waiting, ready, or executing. There is at most one process executing on the CPU at any time. (If there is no useful work to be done, an idling process may be used to perform a null operation.) Any process that could execute is in the ready state; the OS chooses among the ready processes to select the next executing process. A process may not, however, always be ready to run. For instance, a process may be waiting for data from an I/O device or another process, or it may be set to run from a timer that has not yet expired. Such processes are in the waiting state. Figure 6.6 shows the possible transitions between states available to a process. A process goes into the waiting state when it needs data that it has not yet received or when it has finished all its work for the current period. A process goes into the ready state when it receives its required data and when it enters a new period. A process can go into the executing state only when it has all its data, is ready to run, and the scheduler selects the process as the next process to run Some Scheduling Policies A scheduling policy defines how processes are selected for promotion from the ready state to the running state. Every multitasking OS implements some type of scheduling policy. Choosing the right scheduling policy not only ensures that the system will meet all its timing requirements,but it also has a profound influence on the CPU horsepower required to implement the system s functionality.

12 304 CHAPTER 6 Processes and Operating Systems Executing FIGURE 6.6 Chosen to run Ready Scheduling states of a process. Needs data Preempted Received data Needs data Gets data, CPU ready Waiting Schedulability means whether there exists a schedule of execution for the processes in a system that satisfies all their timing requirements. In general, we must construct a schedule to show schedulability, but in some cases we can eliminate some sets of processes as unschedulable using some very simple tests. Utilization is one of the key metrics in evaluating a scheduling policy. Our most basic requirement is that CPU utilization be no more than 100% since we can t use the CPU more than 100% of the time. When we evaluate the utilization of the CPU, we generally do so over a finite period that covers all possible combinations of process executions. For periodic processes, the length of time that must be considered is the hyperperiod, which is the least-common multiple of the periods of all the processes. (The complete schedule for the least-common multiple of the periods is sometimes called the unrolled schedule.) If we evaluate the hyperperiod,we are sure to have considered all possible combinations of the periodic processes.the next example evaluates the utilization of a simple set of processes. Example 6.1 Utilization of a set of processes We are given three processes, their execution times, and their periods: Process Period Execution time P P P The least common multiple of these periods is s.

13 6.1 Multiple Tasks and Multiple Processes 305 In order to calculate the utilization, we have to figure out how many times each process is executed in one hyperperiod: P1 and P2 are each executed five times while P3 is executed once. We can now determine the utilization over the hyperperiod: U This is well below our maximum utilization of 1.0. We will see that some types of timing requirements for a set of processes imply that we cannot utilize 100% of the CPU s execution time on useful work, even ignoring context switching overhead. However, some scheduling policies can deliver higher CPU utilizations than others,even for the same timing requirements. The best policy depends on the required timing characteristics of the processes being scheduled. One very simple scheduling policy is known as cyclostatic scheduling or sometimes as Time Division Multiple Access scheduling. As illustrated in Figure 6.7, a cyclostatic schedule is divided into equal-sized time slots over an interval equal to the length of the hyperperiod H. Processes always run in the same time slot. Two factors affect utilization: the number of time slots used and the fraction of each time slot that is used for useful work. Depending on the deadlines for some of the processes,we may need to leave some time slots empty.and since the time slots are of equal size,some short processes may have time left over in their time slot.we can use utilization as a schedulability measure: the total CPU time of all the processes must be less than the hyperperiod. Another scheduling policy that is slightly more sophisticated is round robin.as illustrated in Figure 6.8, round robin uses the same hyperperiod as does cyclostatic. It also evaluates the processes in order. But unlike cyclostatic scheduling,if a process P 1 P 2 P 3 H P 1 P 2 P 3 H FIGURE 6.7 Cyclostatic scheduling. P 1 P 2 P 3 P 2 P 3 H H FIGURE 6.8 Round-robin scheduling.

14 306 CHAPTER 6 Processes and Operating Systems does not have any useful work to do, the round-robin scheduler moves on to the next process in order to fill the time slot with useful work. In this example, all three processes execute during the first hyperperiod, but during the second one, P 1 has no useful work and is skipped. The processes are always evaluated in the same order.the last time slot in the hyperperiod is left empty;if we have occasional, non-periodic tasks without deadlines, we can execute them in these empty time slots. Round-robin scheduling is often used in hardware such as buses because it is very simple to implement but it provides some amount of flexibility. In addition to utilization, we must also consider scheduling overhead the execution time required to choose the next execution process,which is incurred in addition to any context switching overhead. In general, the more sophisticated the scheduling policy,the more CPU time it takes during system operation to implement it. Moreover, we generally achieve higher theoretical CPU utilization by applying more complex scheduling policies with higher overheads. The final decision on a scheduling policy must take into account both theoretical utilization and practical scheduling overhead Running Periodic Processes We need to find a programming technique that allows us to run periodic processes, ideally at different rates. For the moment,let s think of a process as a subroutine;we will call them p1( ), p2( ), etc. for simplicity. Our goal is to run these subroutines at rates determined by the system designer. Here is a very simple program that runs our process subroutines repeatedly: while (TRUE) { p1(); p2(); } This program has several problems. First, it does not control the rate at which the processes execute the loop runs as quickly as possible, starting a new iteration as soon as the previous iteration has finished. Second, all the processes run at the same rate. Before worrying about multiple rates,let s first make the processes run at a controlled rate. One could imagine controlling the execution rate by carefully designing the code by determining the execution time of the instructions executed during an iteration, we could pad the loop with useless operations (NOPs) to make the execution time of an iteration equal to the desired period. Although some video games were designed this way in the 1970s, this technique should be avoided. Modern processors make it hard to accurately determine execution time, as we saw in Chapter 5. Conditionals anywhere in the program make it even harder to be sure that the loop consumes the same amount of execution time on every iteration. Furthermore, if any part of the program is changed, the entire timing scheme must be re-evaluated.

15 6.1 Multiple Tasks and Multiple Processes 307 A timer is a much more reliable way to control execution of the loop. We would probably use the timer to generate periodic interrupts. Let s assume for the moment that the pall( ) function is called by the timer s interrupt handler. Then this code will execute each process once after a timer interrupt: void pall() { p1(); p2(); } But what happens when a process runs too long? The timer s interrupt will cause the CPU s interrupt system to mask its interrupts,so the interrupt will not occur until after the pall( ) routine returns. As a result, the next iteration will start late. This is a serious problem,but we will have to wait for further refinements before we can fix it. Our next problem is to execute different processes at different rates. If we have several timers,we can set each timer to a different rate.we could then use a function to collect all the processes that run at that rate: void pa() { /* processes that run at rate A*/ p1(); p3(); } void pb() { /* processes that run at rate B */ p2(); p4(); p5(); } This works, but it does require multiple timers, and we may not have enough timers to support all the rates required by a system. An alternative is to use counters to divide the counter rate. If, for example, process p2() must run at 1/3 the rate of p1(), then we can use this code: static int p2count = 0; /* use this to remember count across timer interrupts */ void pall() { p1(); if (p2count >= 2) { /* execute p2() and reset count */ p2(); p2count = 0; } else p2count++; /* just update count in this case */ }

16 308 CHAPTER 6 Processes and Operating Systems This solution allows us to execute processes at rates that are simple multiples of each other. However, when the rates aren t related by a simple ratio, the counting process becomes more complex and more likely to contain bugs. We have developed somewhat more reliable code,but this programming style is still limited in capability and prone to bugs. To improve both the capabilities and reliability of our systems, we need to invent the RTOS. 6.2 PREEMPTIVE REAL-TIME OPERATING SYSTEMS A RTOS executes processes based upon timing constraints provided by the system designer. The most reliable way to meet timing constraints accurately is to build a preemptive OS and to use priorities to control what process runs at any given time. We will use these two concepts to build up a basic RTOS. We will use as our example OS FreeRTOS.org [Bar07]. This operating system runs on many different platforms Preemption Preemption is an alternative to the C function call as a way to control execution.to be able to take full advantage of the timer, we must change our notion of a process as something more than a function call. We must, in fact, break the assumptions of our high-level programming language. We will create new routines that allow us to jump from one subroutine to another at any point in the program. That, together with the timer,will allow us to move between functions whenever necessary based upon the system s timing constraints. We want to share the CPU across two processes. The kernel is the part of the OS that determines what process is running. The kernel is activated periodically by the timer. The length of the timer period is known as the time quantum because it is the smallest increment in which we can control CPU activity. The kernel determines what process will run next and causes that process to run. On the next timer interrupt, the kernel may pick the same process or another process to run. Note that this use of the timer is very different from our use of the timer in the last section. Before, we used the timer to control loop iterations, with one loop

17 6.2 Preemptive Real-Time Operating Systems 309 iteration including the execution of several complete processes. Here, the time quantum is in general smaller than the execution time of any of the processes. How do we switch between processes before the process is done? We cannot rely on C-level mechanisms to do so. We can, however, use assembly language to switch between processes. The timer interrupt causes control to change from the currently executing process to the kernel; assembly language can be used to save and restore registers.we can similarly use assembly language to restore registers not from the process that was interrupted by the timer but to use registers from any process we want. The set of registers that define a process are known as its context and switching from one process s register set to another is known as context switching. The data structure that holds the state of the process is known as the process control block Priorities How does the kernel determine what process will run next? We want a mechanism that executes quickly so that we don t spend all our time in the kernel and starve out the processes that do the useful work. If we assign each task a numerical priority, then the kernel can simply look at the processes and their priorities, see which ones actually want to execute (some may be waiting for data or for some event),and select the highest priority process that is ready to run. This mechanism is both flexible and fast. The priority is a non-negative integer value. The exact value of the priority is not as important as the relative priority of different processes. In this book, we will generally use priority 1 as the highest priority,but it is equally reasonable to use 1 or 0 as the lowest priority value (as FreeRTOS.org does). Example 6.2 shows how priorities can be used to schedule processes. Example 6.2 Priority-driven scheduling For this example, we will adopt the following simple rules: Each process has a fixed priority that does not vary during the course of execution. (More sophisticated scheduling schemes do, in fact, change the priorities of processes to control what happens next.) The ready process with the highest priority (with 1 as the highest priority of all) is selected for execution.

18 310 CHAPTER 6 Processes and Operating Systems A process continues execution until it completes or it is preempted by a higher-priority process. Let s define a simple system with three processes as seen below. Process Priority Execution time P P P In addition to describing the properties of the processes in general, we need to know the environmental setup. We assume that P2 is ready to run when the system is started, P1 is released at time 15, and P3 is released at time 18. Once we know the process properties and the environment,we can use the priorities to determine which process is running throughout the complete execution of the system. P2 release P1 release P3 release P2 P1 P2 P When the system begins execution,p2 is the only ready process,so it is selected for execution. At time 15, P1 becomes ready; it preempts P2 and begins execution since it has a higher priority. Since P1 is the highest-priority process in the system, it is guaranteed to execute until it finishes. P3 s data arrive at time 18, but it cannot preempt P1. Even when P1 finishes, P3 is not allowed to run. P2 is still ready and has higher priority than P3. Only after both P1 and P2 finish can P3 execute Processes and Context The best way to understand processes and context is to dive into an RTOS implementation. We will use the FreeRTOS.org kernel as an example; in particular, we will use version for the ARM7 AT91 platform. A process is known in FreeRTOS.org as a task. Task priorities in FreeRTOS.org are ranked opposite to the convention we use in the rest of the book: higher numbers denote higher priorities and the priority 0 task is the idle task.

19 6.2 Preemptive Real-Time Operating Systems 311 timer vpreemptivetick portsave_context portrestore_context vtaskswitchcontext task 1 task 2 FIGURE 6.9 Sequence diagram for freertos.org context switch. To understand the basics of a context switch, let s assume that the set of tasks is in steady state: Everything has been initialized, the OS is running, and we are ready for a timer interrupt. Figure 6.9 shows a sequence diagram for a context switch in freertos.org.this diagram shows the application tasks,the hardware timer,and all the functions in the kernel that are involved in the context switch: vpreemptivetick() is called when the timer ticks. portsave_context() swaps out the current task context. vtaskswitchcontext ( ) chooses a new task. portrestore_context() swaps in the new context. Here is the code for vpreemptivetick() in the file portisr.c: void vpreemptivetick( void ) { /* Save the context of the interrupted task. */ portsave_context(); /* WARNING - Do not use local (stack) variables here. Use globals if you must! */ static volatile unsigned portlong uldummy; /* Clear tick timer interrupt indication. */ uldummy = porttimer_reg_base_ptr->tc_sr; /* Increment the RTOS tick count, then look for the highest priority task that is ready to run. */ vtaskincrementtick(); vtaskswitchcontext();

20 312 CHAPTER 6 Processes and Operating Systems /* Acknowledge the interrupt at AIC level... */ AT91C_BASE_AIC->AIC_EOICR = portclear_aic_interrupt; } /* Restore the context of the new task. */ portrestore_context(); vpreemptivetick() has been declared as a naked function; this means that it does not use the normal procedure entry and exit code that is generated by the compiler. Because the function is naked, the registers for the process that was interrupted are still available; vpreemptivetick() doesn t have to go to the procedure call stack to get their values. This is particularly handy since the procedure mechanism would save only part of the process state, making the state-saving code a little more complex. The first thing that this routine must do is save the context of the task that was interrupted. To do this, it uses the routine portsave_context(), which saves all the context of the stack. It then performs some housekeeping, such as incrementing the tick count.the tick count is the internal timer that is used to determine deadlines. After the tick is incremented,some tasks may have become ready as they passed their deadlines. Next, the OS determines which task to run next using the routine vtaskswitchcontext(). After some more housekeeping, it uses port RESTORE_CONTEXT() to restore the context of the task that was selected by vtaskswitchcontext(). The action of portrestore_context() causes control to transfer to that task without using the standard C return mechanism. The code for portsave_context(), in the file portmacro.h, is defined as a macro and not as a C function. It is structured in this way so that it doesn t disturb the register values that need to be saved. Because it is a macro, it has to be written in a hard-to-read way all code must be on the same line or end-of-line continuations (back slashes) must be used. Here is the code in more readable form, with the end-of-line continuations removed and the assembly language that is the heart of this routine temporarily removed.: #define portsave_context() { extern volatile void * volatile pxcurrenttcb; extern volatile unsigned portlong ulcriticalnesting; } /* Push R0 as we are going to use the register. */ asm volatile( /* assembly language code here */ ); ( void ) ulcriticalnesting; ( void ) pxcurrenttcb; The asm statement allows assembly language code to be introduced in-line into the C program. The keyword volatile tells the compiler that the assembly language

21 6.2 Preemptive Real-Time Operating Systems 313 may change register values,which means that many compiler optimizations cannot be performed across the assembly language code. The code uses ulcriticalnesting and pxcurrenttcb simply to avoid compiler warnings about unused variables the variables are actually used in the assembly code, but the compiler cannot see that. The asm statement requires that the assembly language be entered as strings, one string per line, which makes the code hard to read. The fact that the code is included in a #define makes it even harder to read. Here is a cleaned-up version of the assembly language code from the asm volatile( ) statement: STMDB SP!, {R0} /* Set R0 to point to the task stack pointer. */ STMDB SP, {SP}^ NOP SUB SP, SP, #4 LDMIA SP!,{R0} /* Push the return address onto the stack. */ STMDB R0!, {LR} /* Now we have saved LR we can use it instead of R0. */ MOV LR, R0 /* Pop R0 so we can save it onto the system mode stack. */ LDMIA SP!, {R0} /* Push all the system mode registers onto the task stack. */ STMDB LR,{R0-LR}^ NOP SUB LR, LR, #60 /* Push the SPSR onto the task stack. */ MRS R0, SPSR STMDB LR!, {R0} LDR R0, =ulcriticalnesting LDR R0, [R0] STMDB LR!, {R0} /*Store the new top of stack for the task. */ LDR R0, =pxcurrenttcb LDR R0, [R0] STR LR, [R0] Here is the code for vtaskswitchcontext( ), which is defined in the file tasks.c: void vtaskswitchcontext( void ) { if( uxschedulersuspended!= ( unsigned portbase_type ) pdfalse )

22 314 CHAPTER 6 Processes and Operating Systems { return; } /* The scheduler is currently suspended - do not allow a context switch. */ xmissedyield = pdtrue; /* Find the highest priority queue that contains ready tasks. */ while( listlist_is_empty(&( pxreadytaskslists[ uxtopreadypriority ]) ) ) { uxtopreadypriority; } } /* listget_owner_of_next_entry walks through the list, so the tasks of the same priority get an equal share of the processor time. */ listget_owner_of_next_entry( pxcurrenttcb, &(pxreadytaskslists[uxtopreadypriority ] ) ); vwritetracetobuffer(); This function is relatively straightforward it walks down the list of tasks to identify the highest-priority task. This function is designed to deterministically choose the next task to run as long as the selected task is of equal or higher priority to the interrupted task; the list of tasks that is checked is determined by the variable uxtopreadypriority. Each list contains the set of processes with the same priority; once the proper priority has selected by determining the value of uxtopreadypriority, the system rotates through processes of equal priority by walking down their list. The portrestore_context() routine is also defined in portmacro.h and is implemented as a macro with embedded assembly language. Here is the macro with the line continuations and assembly language code removed: #define portrestore_context() { extern volatile void * volatile pxcurrenttcb; extern volatile unsigned portlong ulcriticalnesting; /* Set the LR to the task stack. */ asm volatile (/* assembly language code here */);

23 6.2 Preemptive Real-Time Operating Systems 315 } ( void ) ulcriticalnesting; ( void ) pxcurrenttcb; Here is the assembly language code for portrestore_context: LDR R0, =pxcurrenttcb LDR R0, [R0] LDR LR, [R0] /* The critical nesting depth is the first item on the stack. */ /* Load it into the ulcriticalnesting variable. */ LDR R0, =ulcriticalnesting LDMFD LR!, {R1} STR R1, [R0] /* Get the SPSR from the stack. */ LDMFD LR!, {R0} MSR SPSR, R0 /* Restore all system mode registers for the task. */ LDMFD LR, {R0-R14}ˆ NOP /* Restore the return address. */ LDR LR, [LR, #+60] /* And return - correcting the offset in the LR to obtain the */ /* correct address. */ SUBS PC, LR, # Processes and Object-Oriented Design We need to design systems with processes as components. In this section, we survey the ways we can describe processes in UML and how to use processes as components in object-oriented design. UML often refers to processes as active objects, that is, objects that have independent threads of control. The class that defines an active object is known as an active class. Figure 6.10 shows an example of a UML active class. It has all the normal characteristics of a class, including a name, attributes, and operations. It also provides a set of signals that can be used to communicate with the process.a signal is an object that is passed between processes for asynchronous communication. We describe signals in more detail in Section We can mix active objects and normal objects when describing a system. Figure 6.11 shows a simple collaboration diagram in which an object is used as an interface between two processes: p1 uses the w object to manipulate its data before the data is sent to the master process.

24 316 CHAPTER 6 Processes and Operating Systems processclass 1 myattributes myoperations( ) Signals start resume FIGURE 6.10 An active class in UML. p1: processclass1 a: rawmsg w: wrapperclass ahat: fullmsg master: masterclass FIGURE 6.11 A collaboration diagram with active and normal objects. 6.3 PRIORITY-BASED SCHEDULING Now that we have a priority-based context switching mechanism, we have to determine an algorithm by which to assign priorities to processes. After assigning priorities, the OS takes care of the rest by choosing the highest-priority ready process. There are two major ways to assign priorities: static priorities that do not change during execution and dynamic priorities that do change. We will look at examples of each in this section Rate-Monotonic Scheduling Rate-monotonic scheduling (RMS), introduced by Liu and Layland [Liu73], was one of the first scheduling policies developed for real-time systems and is still very widely used. RMS is a static scheduling policy. It turns out that these fixed priorities are sufficient to efficiently schedule the processes in many situations. The theory underlying RMS is known as rate-monotonic analysis (RMA).This theory, as summarized below, uses a relatively simple model of the system. All processes run periodically on a single CPU. Context switching time is ignored.

25 6.3 Priority-Based Scheduling 317 There are no data dependencies between processes. The execution time for a process is constant. All deadlines are at the ends of their periods. The highest-priority ready process is always selected for execution. The major result of RMA is that a relatively simple scheduling policy is optimal under certain conditions. Priorities are assigned by rank order of period, with the process with the shortest period being assigned the highest priority. This fixed-priority scheduling policy is the optimum assignment of static priorities to processes, in that it provides the highest CPU utilization while ensuring that all processes meet their deadlines. Example 6.3 illustrates RMS. Example 6.3 Rate-monotonic scheduling Here is a simple set of processes and their characteristics. Process Execution time Period P1 1 4 P2 2 6 P Applying the principles of RMA, we give P1 the highest priority, P2 the middle priority, and P3 the lowest priority. To understand all the interactions between the periods, we need to construct a time line equal in length to hyperperiod, which is 12 in this case. P3 P2 P Time All three periods start at time zero. P1 s data arrive first. Since P1 is the highest-priority process, it can start to execute immediately. After one time unit, P1 finishes and goes out of the ready state until the start of its next period. At time 1, P2 starts executing as the

26 318 CHAPTER 6 Processes and Operating Systems highest-priority ready process. At time 3, P2 finishes and P3 starts executing. P1 s next iteration starts at time 4, at which point it interrupts P3. P3 gets one more time unit of execution between the second iterations of P1 and P2, but P3 does not get to finish until after the third iteration of P1. Consider the following different set of execution times for these processes, keeping the same deadlines. Process Execution time Period P1 2 4 P2 3 6 P In this case, we can show that there is no feasible assignment of priorities that guarantees scheduling. Even though each process alone has an execution time significantly less than its period, combinations of processes can require more than 100% of the available CPU cycles. For example, during one 12 time-unit interval, we must execute P1 three times, requiring 6 units of CPU time; P2 twice, costing 6 units of CPU time; and P3 one time, requiring 3 units of CPU time. The total of 6+6+3=15units of CPU time is more than the 12 time units available, clearly exceeding the available CPU capacity. Liu and Layland [Liu73] proved that the RMA priority assignment is optimal using critical-instant analysis. We define the response time of a process as the time at which the process finishes. The critical instant for a process is defined as the instant during execution at which the task has the largest response time. It is easy to prove that the critical instant for any process P, under the RMA model, occurs when it is ready and all higher-priority processes are also ready if we change any higher-priority process to waiting, then P s response time can only go down. We can use critical-instant analysis to determine whether there is any feasible schedule for the system. In the case of the second set of execution times in Example 6.3,there was no feasible schedule. Critical-instant analysis also implies that priorities should be assigned in order of periods. Let the periods and computation times of two processes P 1 and P 2 be 1, 2 and T 1, T 2, with 1 < 2. We can generalize the result of Example 6.3 to show the total CPU requirements for the two processes in two cases. In the first case, let P 1 have the higher priority. In the worst case we then execute P 2 once during its period and as many iterations of P 1 as fit in the same interval. Since there are 2 / 1 iterations of P 1 during a single period of P 2, the required constraint on CPU time, ignoring context switching overhead, is 2 T 1 T 2 2. (6.4) 1