Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
CPU Scheduling The scheduler is the component of the kernel that selects which process to run next. The scheduler (or process scheduler, as it is sometimes called) can be viewed as the code that divides the finite resource of processor time between the runnable processes on a system. The scheduler is the basis of a multitasking operating system such as Linux. By deciding what process can run, the scheduler is responsible for best utilising the system and giving the impression that multiple processes are simultaneously executing. The idea behind the scheduler is simple. To best utilise processor time, assuming there are runnable processes, a process should always be running. If there are more processes than processors in a system, some processes will not always be running. These processes are waiting to run. Deciding what process runs next, given a set of runnable processes, is a fundamental decision the scheduler must make. Multitasking operating systems come in two flavours: • • cooperative multitasking and preemptive multitasking. Linux, like all Unix variants and most modern operating systems, provides preemptive multitasking. In preemptive multitasking, the scheduler decides when a process is to cease running and a new process is to resume running. The act of involuntarily suspending a running process is called preemption. The time a process runs before it is preempted is predetermined, and is called the timeslice of the process. The timeslice, in effect, gives each process a slice of the processor's time. Managing the timeslice enables the scheduler to make global scheduling decisions for the system. It also prevents any one process from monopolising the system. This timeslice is dynamically calculated in the Linux scheduler to provide some interesting benefits. Conversely, in cooperative multitasking, a process does not stop running until it voluntary decides to do so. The act of a process voluntarily suspending itself is called yielding. The shortcomings of this approach are numerous: The scheduler cannot make global decisions regarding how long processes run, processes can monopolise the processor for longer than the user desires, and a hung process that never yields can potentially bring down the entire system. Thankfully, most operating systems designed in the last decade have provided preemptive multitasking.. Unix has been preemptively multitasked since the beginning. The Linux kernel, unlike most other Unix variants and many other operating systems, is a fully preemptive kernel. In non-preemptive kernels, kernel code runs until completion. That is, the scheduler is not capable of rescheduling a task while it is in the kernel—kernel code is scheduled cooperatively, not preemptively. Kernel code runs until it finishes (returns to user-space) or explicitly blocks. Policy Policy is the behaviour of the scheduler that determines what runs when. A scheduler's policy often determines the overall feel of a system and is responsible for optimally utilising processor time. Therefore, it is very important. 1 I/O-Bound Versus Processor-Bound Processes Processes can be classified as either I/O-bound or processor-bound. The former is characterised as a process that spends much of its time submitting and waiting on I/O requests. Consequently, such a process is often runnable, but only for short periods, because it will eventually block waiting on more I/O (this is any type of I/O, such as keyboard activity, and not just disk I/O). Conversely, processorbound processes spend much of their time executing code. They tend to run until they are preempted because they do not block on I/O requests very often. Because they are not I/O-driven, however, system response does not dictate that the scheduler run them often. The scheduler policy for processorbound processes, therefore, tends to run such processes less frequently but for longer periods. Of course, these classifications are not mutually exclusive. The scheduler policy in Unix variants tends to explicitly favour I/O-bound processes. The scheduling policy in a system must attempt to satisfy two conflicting goals: fast process response time (low latency) and high process throughput. To satisfy these requirements, schedulers often employ complex algorithms to determine the most worthwhile process to run, while not compromising fairness to other, lower priority, processes. Favouring I/O-bound processes provides improved process response time, because interactive processes are I/O-bound. Linux, to provide good interactive response, optimises for process response (low latency), thus favouring I/O-bound processes over processor-bound processors. This is done in a way that does not neglect processor-bound processes. Timeslice The timeslice is the numeric value that represents how long a task can run until it is preempted. The scheduler policy must dictate a default timeslice, which is not simple. A timeslice that is too long will cause the system to have poor interactive performance; the system will no longer feel as if applications are being concurrently executed. A timeslice that is too short will cause significant amounts of processor time to be wasted on the overhead of switching processes, as a significant percentage of the system's time will be spent switching from one process with a short timeslice to the next. Furthermore, the conflicting goals of I/O-bound versus processor-bound processes again arise; I/O-bound processes do not need longer timeslices, whereas processor-bound processes crave long timeslices (to keep their caches hot, for example). With this argument, it would seem that any long timeslice would result in poor interactive performance. In many operating systems, this observation is taken to heart, and the default timeslice is rather low— for example, 20ms. Linux, however, takes advantage of the fact that the highest priority process always runs. The Linux scheduler bumps the priority of interactive tasks, enabling them to run more frequently. Consequently, the Linux scheduler offers a relatively high default timeslice (see Figure 1). Furthermore, the Linux scheduler dynamically determines the timeslice of a process based on priority. This enables higher priority, allegedly more important, processes to run longer and more often. Implementing dynamic timeslices and priorities provides robust scheduling performance. 2 Figure 1 Note that a process does not have to use all its timeslice at once. For example, a process with a 100 millisecond timeslice does not have to run for 100 milliseconds in one go or risk losing the remaining timeslice. Instead, the process can run on five different reschedules for 20 milliseconds each. Thus, a large timeslice also benefits interactive tasks—while they do not need such a large timeslice all at once, it ensures they remain runnable for as long as possible. When a process's timeslice runs out, the process is considered expired. A process with no timeslice is not eligible to run until all other processes have exhausted their timeslice (that is, they all have zero timeslice remaining). At that point, the timeslices for all processes are recalculated. The Linux scheduler employs an interesting algorithm for handling timeslice exhaustion. Timeslice is sometimes called quantum or processor slice in other systems. Linux calls it timeslice. Scheduling Criteria Many criteria have been suggested for comparing CPU scheduling algorithms. Which characteristics are used for comparison can make a substantial difference in the determination of the best algorithm. Criteria that are used include the following: • CPU utilisation. It is desirable to keep the CPU as busy as possible. CPU utilisation may range from 0 to 100 percent. In a real system, it should range from 40 percent (for a lightly loaded system) to 90 percent (for a heavily used system). • Throughput. If the CPU is busy, then work is being done. One measure of work is the number of processes that are completed per time unit, called throughput. For long processes, this rate may be one process per hour; for short transactions, throughput might be 10 processes per second. • Turnaround time. From the point of view of a particular process, the important criterion is how long it takes to execute that process. The interval from the time of submission to the time of completion is the turnaround time. 3 • Waiting time. The CPU scheduling algorithm does not affect the amount of time during which a process executes or does I/O; it affects only the amount of time that a process spends waiting in the ready queue. Waiting time is the sum of the periods spent waiting in the ready queue. • Response time. The response time, is the amount of time it takes to start responding, but not the time that it takes to output that response. Often, a process can produce some output fairly early, and can continue computing new results while previous results are being output to the user. It is desirable to maximise CPU utilisation and throughput, and to minimise turnaround time, waiting time, and response time. In most cases, we optimise the average measure. However, there are circumstances when it is desirable to optimise the minimum or maximum values, rather than the average. For example, to guarantee that all users get good service, we may want to minimise the maximum response time. Scheduling Algorithms CPU scheduling deals with the problem of deciding which of the processes in the ready queue is to be allocated the CPU. First-Come, First-Served By far the simplest CPU scheduling algorithm is the first-come, first-served scheduling (FCFS) algorithm. With this scheme, the process that requests the CPU first is allocated the CPU first. The implementation of the FCFS policy is easily managed with a FIFO queue. When a process enters the ready queue, its PCB is linked onto the tail of the queue. When the CPU is free, it is allocated to the process at the head of the queue. The running process is then removed from the queue. The code for FCFS scheduling is simple to write and understand. The average waiting time under the FCFS policy, however, is often quite long. Consider the following set of processes that arrive at time 0, with the length of the CPU-burst time given in milliseconds: Process A B Ratio Estimated Waiting B/A runtime P1 2 0 0 P2 60 2 0.03 P3 1 62 62 P4 3 63 21 P5 50 66 1.32 4 The waiting time is 0 milliseconds for process P1, 2 milliseconds for process P2, and 62 milliseconds for process P3, 63 millisecond for P4 and 66 ms for P5. Thus, the average waiting time is (0 + 2 + 62 + 63 + 66)/5 = 38.6 milliseconds. Now consider the performance of FCFS scheduling in a dynamic situation. Assume we have one CPUbound process and many I/O-bound processes. As the processes flow around the system, the following scenario may result. The CPU-bound process will get the CPU and hold it. During this time, all the other processes will finish their I/O and move into the ready queue, waiting for the CPU. While the processes wait in the ready queue, the I/O devices are idle. Eventually, the CPU-bound process finishes its CPU burst and moves to an I/O device. All the I/O-bound processes, which have very short CPU bursts, execute quickly and move back to the I/O queues. At this point, the CPU sits idle. The CPUbound process will then move back to the ready queue and be allocated the CPU. Again, all the I/O processes end up waiting in the ready queue until the CPU-bound process is done. There is a convoy effect, as all the other processes wait for the one big process to get off the CPU. This effect results in lower CPU and device utilisation than might be possible if the shorter processes were allowed to go first. The FCFS scheduling algorithm is non preemptive. Once the CPU has been allocated to a process, that process keeps the CPU until it releases the CPU, either by terminating or by requesting I/O. The FCFS algorithm is particularly unsuitable for time-sharing systems, where it is important that each user get a share of the CPU at regular intervals Shortest-Job-First A different approach to CPU scheduling is the shortest-job-first (SJF) algorithm i.e. if the CPU is available, it is assigned to the process that has the smallest next CPU burst. If two processes have the same length next CPU burst, FCFS scheduling is used to arbitrate. Note that a more appropriate term would be the shortest next CPU burst, because the scheduling is done by examining the length of the next CPU-burst of a process, rather than its total length.As an example, consider the following set of processes, with the length of the CPU burst time given in milliseconds: Process A Estimated runtime B Waiting Ratio B/A P3 1 0 0 P1 2 1 0.5 P4 3 3 1.0 P5 50 6 0.1 P2 60 56 0.9 The waiting time is 1 millisecond for process P1, 56 milliseconds for process P2, 0 milliseconds for process P3, 3 milliseconds for process P4 and 6 milliseconds for process P5. Thus, the average waiting time is (1 + 56 + 0 +3 + 6)/5 = 13.2 milliseconds. If we were using the FCFS scheduling, then the average waiting time would be 38.6 milliseconds. 5 The SJF scheduling algorithm gives the minimum average waiting time for a given set of processes. By moving a short process before a long one the waiting time of the short process decreases more than it increases the waiting time of the long process. Consequently, the average waiting time decreases. The real difficulty with the SJF algorithm is knowing. the length of the next CPU request. For longterm (job) scheduling in a batch system, we can use as the length the process time limit that a user specifies when he submits the job. Thus, users are motivated to estimate the process time limit accurately, since a lower value may mean faster response. (Too low a value will cause a time-limitexceeded error and require resubmission.) SJF scheduling is used frequently in long-term scheduling. Although the SJF algorithm is optimal, it cannot be implemented at the level of short-term CPU scheduling. There is no way to know the length of the next CPU burst. One approach is to try to approximate SJF scheduling. We may not know the length of the next CPU burst, but we may be able to predict its value. We expect that the next CPU burst will be similar in length to the previous ones. Thus, by computing an approximation of the length of the next CPU burst, we can pick the process with the shortest predicted CPU burst. Priority Scheduling The SJF algorithm is a special case of the general priority scheduling algorithm. A priority is associated with each process, and the CPU is allocated to the process with the highest priority. Equal-priority processes are scheduled in FCFS order. Processes with a higher priority will run before those with a lower priority, while processes with the same priority are scheduled round-robin (one after the next, repeating). On some systems, Linux included, processes with a higher priority also receive a longer timeslice. The runnable process with timeslice remaining and the highest priority always runs. Both the user and the system may set a processes priority to influence the scheduling behavior of the system. Linux builds on this idea and provides dynamic priority-based scheduling. This concept begins with the initial base priority, and then enables the scheduler to increase or decrease the priority dynamically to fulfill scheduling objectives. For example, a process that is spending more time waiting on I/O than running is clearly I/O bound. Under Linux, it receives an elevated dynamic priority. As a counterexample, a process that continually uses up its entire timeslice is processor bound—it would receive a lowered dynamic priority. The Linux kernel implements two separate priority ranges. The first is the nice value, a number from 20 to 19 with a default of zero. Larger nice values correspond to a lower priority—you are being nice to the other processes on the system. Processes with a lower nice value (higher priority) run before processes with a higher nice value (lower priority). The nice value also helps determine how long a timeslice the process receives. A process with a nice value of –20 receives the maximum timeslice, whereas a process with a nice value of 19 receives the minimum timeslice. Nice values are the standard priority range used in all Unix systems. The second range is the real-time priority, which will be discussed later. By default, it ranges from zero to 99. All real-time processes are at a higher priority than normal processes. Linux implements realtime priorities in accordance with POSIX. Most modern Unix systems implement a similar scheme. 6 As an example, consider the following set of processes, assumed to have arrived at time 0, in the order P1, P2, ..., P5. with the length of the CPU-burst time given in milliseconds: Process Burst Time Priority P1 10 3 P2 1 1 P3 2 3 P4 1 4 P5 5 2 Using priority scheduling, we would schedule these processes as follows: P2 P5 0 1 P1 6 P3 P4 16 18 19 The average waiting time is 12 milliseconds. Priority scheduling can be either preemptive or non pre-emptive. When a process arrives at the ready queue, its priority is compared with the priority of the currently running process. A preemptive priority scheduling algorithm will preempt the CPU if the priority of the newly arrived process is higher than is the priority of the currently running process. A non pre-emptive priority scheduling algorithm will simply put the new process at the head of the ready queue. A major problem with priority scheduling algorithms is indefinite blocking or starvation. A process that is ready to run but unable to get CPU time can be considered blocked. A priority scheduling algorithm can leave some low-priority processes waiting indefinitely for the CPU. In a heavily loaded computer system, a steady stream of higher-priority processes can prevent a low-priority process from ever getting the CPU. Generally, one of two things will happen. Either the process will eventually be run (when the system is finally lightly loaded), or the computer system will eventually crash and lose all unfinished low-priority processes. A solution to the problem of indefinite blockage of low-priority processes is aging. Aging is a technique of gradually increasing the priority )of processes that wait in the system for a long time. For example, if priorities range from 0 (low) to 127 (high), we could increment the priority of a waiting process by 1 every 15 minutes. Eventually, even a process with an initial priority of 0 would have the highest priority in the system and would be executed. Round-Robin Scheduling The round-robin (RR) scheduling algorithm is designed especially for time-sharing systems. It is similar to FCFS scheduling, but preemption is added switch between processes. A small unit of time, called a time quantum, or time slice, is defined. A time quantum is generally from 10 to 100 milliseconds. The ready queue is treated as a circular queue. The CPU scheduler goes around the ready queue, allocating the CPU to each process for a time interval of up to 1 time quantum. To implement RR scheduling, the ready queue is kept as a FIFO queue of processes. New processes are added to the tail of the ready queue. The CPU scheduler picks the first process from the ready queue, sets a timer to interrupt after 1 time quantum, and dispatches the process. One of two things will then happen. The process may have a CPU burst of less than 1, time quantum. In this case, the process itself will release the CPU voluntarily. The scheduler will then proceed to the next process in the ready queue. Otherwise, if the CPU burst of the currently running process is longer than 1 time quantum, the 7 timer will go off and will cause an interrupt to the operating system. A context switch will be executed, and the process will be put at the tail of the ready queue. The CPU scheduler will then select the next process in the ready queue. The average waiting time under the RR policy, however, is often quite long. Consider the following set of processes that arrive at time 0, with the length of the CPU-burst time given in milliseconds: Process P1 P2 P3 Burst Time 24 3 3 Using a time quantum of 4 milliseconds, then process P1 gets the first 4 milliseconds. Since it requires another 20 milliseconds, it is preempted after the first time quantum, and the CPU is given to the next process in the queue, process P2. Since process P2 does not need 4 milliseconds, it quits before its time quantum expires. The CPU is then given to the next process, process P3. Once each process has received 1 time quantum, the CPU is returned to process P1 for an additional time quantum. The resulting RR schedule is P1 0 P2 4 P3 7 P1 10 P1 14 P1 18 P1 22 P1 26 30 The performance of the RR algorithm depends heavily on the size of the time quantum. At one extreme, if the time quantum is very large (infinite), the RR policy is the same as the FCFS policy. If the time quantum is very small (say 1 microsecond), the RR approach is called processor sharing, and appears (in theory) to the users as though each of n processes has its own processor running at 1/n the speed of the real processor. In software, however, the effect of context switching on the performance needs to be considered. It is assumed that there is only one process of 10 time units. If the quantum is 12 time units, the process finishes in less than 1 time quantum, with no overhead. If the quantum is 6 time units, however, the process requires 2 quanta, resulting in a context switch, thus slowing the execution of the process Thus, we want the time quantum to be large with respect to the context-switch time. If the contextswitch time is approximately 10 percent of the time quantum, then about 10 percent of the CPU time will be spent in context switch. Turnaround time also depends on the size of the time quantum. The average turnaround time of a set of processes does not necessarily improve as the time-quantum size increases. In general, the average turnaround time can be improved if most processes finish their next CPU burst in a single time quantum. Process Ageing One of the problems with priority scheduling is that processes can become starved. This occurs when low priority processes are continually gazumped by higher priority processes and never get to run. One way round this is to introduce process ageing. A 15 B 14 C 13 D 12 E F 12 10 A 15 8 B 14 A 16 C 13 B 15 D 12 E 12 F 10 C 14 D 13 E F 13 11 C 14 D 13 E 13 F 11 A 16 C 15 D 14 E F 14 12 A 16 C 15 D 14 E 14 A 15 B 15 B 16 B 14 A 17 C 16 D 15 E 15 F 12 B F 15 13 After each process runs, all other processes have their priorities incremented, whilst the running process has it’s priority set back to it’s original priority and placed back into the queue in ascending order of priorities. This means that the F, which has the lowest priority, will eventually reach the front of the queue. Multilevel Queue Scheduling Another class of scheduling algorithms has been created for situations in which processes are easily classified into different groups. For example, a common division is made between foreground (interactive) processes and background (batch) processes. These two types of processes have different response-time requirements, and so might have different scheduling needs. In addition, foreground processes may have priority (externally defined) over background processes. A multilevel queue-scheduling algorithm partitions the ready queue into several separate queues. The processes are permanently assigned to one queue, generally based on some property of the process, 9 such as memory size, process priority, or process type. Each queue has its own scheduling algorithm. For example, separate queues might be used for foreground and background processes. The foreground queue might be scheduled by an RR algorithm, while the background queue is scheduled by an FCES algorithm.In addition, there must be scheduling between the queues, which is commonly implemented as a fixed-priority preemptive scheduling. For example, the foreground queue may have absolute priority over the background queue. Example - a multilevel queue scheduling algorithm with five queues: Highest priority System processes Interactive processes Interactive editing processes Batch processes Student processes Lowest priority Each queue has absolute priority over lower-priority queues. No process in the batch queue, for example, could run unless the queues for system processes, interactive processes, and interactive editing processes were all empty. If an interactive editing process entered the ready queue while a batch process was running, the batch process would be preempted. Another possibility is to time slice between the queues. Each queue gets a certain portion of the CPU time, which it can then schedule among the various processes in its queue. For instance, in the foreground-background queue example, the foreground queue can be given 80 percent of the CPU time for RR scheduling among its processes, whereas the background queue receives 20 percent of the CPU to give to its processes in a FCFS manner. Multilevel Feedback Queue Scheduling Normally, in a multilevel queue-scheduling algorithm, processes are permanently assigned to a queue on entry to the system. Processes do not move between queues. If there are separate queues for foreground and background processes, for example, processes do not move from one queue to the other, since processes do not change their foreground or background nature. This setup has the advantage of low scheduling overhead, but is inflexible. Multilevel feedback queue scheduling, however, allows a process to move between queues. The idea is to separate processes with different CPU-burst lowest priority characteristics. If a process uses too much CPU time, it will be moved to a lower-priority queue. This scheme leaves I/O-bound and interactive processes in the higher-priority queues. Similarly, a process that waits too long in a lower-priority queue may be moved to a higherpriority queue. This form of aging prevents starvation. Linux Linux uses MFQ with 32 run queues. System run queues use queues 0 to 7, processes executing in user space use 8 to 31. Inside each queue UNIX uses round robin scheduling. Various distributions of UNIX 10 have different time quanta, but all are less than 100 micro seconds. Every process has a ‘nice’ priority but is only used to influence and not solely determine priorities. Real-time Operating Systems Definition: A real-time operating system (RTOS) is an operating system that guarantees a certain capability within a specified time constraint. For example, an operating system might be designed to ensure that a certain object was available for a robot on an assembly line. In what is usually called a "hard" real-time operating system, if the calculation could not be performed for making the object available at the designated time, the operating system would terminate with a failure. In a "soft" real-time operating system, the assembly line would continue to function but the production output might be lower as objects failed to appear at their designated time, causing the robot to be temporarily unproductive. Hard vs. Soft Real-time The issue of predictability is of key concern in real-time systems. In fact, the term "predictable" can often be found in the multitude of definitions of real-time in the literature. Both periodic and aperiodic tasks have strict timing requirements in the form of deadlines. That is, the scheduler must be able to guarantee that each task is allocated a resource by a particular point in time, based on the task's parameters. In order to accomplish this, every allocation of any resource to any task must incur a latency that is deterministic or that can at least be predicted within a statistical margin of error. Hard real-time tasks are required to meet all deadlines for every instance, and for these activities the failure to meet even a single deadline is considered catastrophic. Examples are found in flight navigation, automobile, and spacecraft systems. In contrast, soft real-time tasks allow for a statistical bound on the number of deadlines missed, or on the allowable lateness of completing processing for an instance in relation to a deadline. Soft real-time applications include media streaming in distributed systems and non-mission-critical tasks in control systems. Periodic Real-time Tasks In general, a real-time task requires a specified amount of particular resources during specified periods of time. A periodic task is a task that requests resources at time values representing a periodic function. That is, there is a continuous and deterministic pattern of time intervals between requests of a resource. In addition to this requirement, a real-time periodic task must complete processing by a specified deadline relative to the time that it acquires the processor (or some other resource). For simplicity, assume that a real-time task has a constant request period (ie, must begin execution on the processor every n milliseconds). For example, a robotics application may consist of a number of periodic real-time tasks, which perform activities such as sensor data collection or regular network transmissions. Suppose the robot runs a task that must collect infrared sensor data to determine if a barrier is nearby at regular time intervals. If the configuration of this task requires that every 5 milliseconds it must complete 2 milliseconds of collecting and processing the sensor data, then the task is a periodic real-time task. Aperiodic Real-time Tasks 11 The aperiodic real-time task model involves real-time activities that request a resource during nondeterministic request periods. Each task instance is also associated with a specified deadline, which represents the time necessary for it to complete its execution. Examples of aperiodic real-time tasks are found in event-driven real-time systems, such as ejection of a pilot seat when the command is given to the navigation system in a jet fighter. Many, less timesensitive, applications also arise in distributed systems involving real-time streaming media (ie, endhost routing over a logical overlay). RTOS Scheduling The RTOS scheduling policy is one of the most important features of the RTOS to consider when assessing its usefulness in a real-time application. There are a multitude of scheduling algorithms and scheduler characteristics. An RTOS requires a specific set of attributes to be effective. The task scheduling should be priority based. A task scheduler for an RTOS has multiple levels of interrupt priorities where the higher priority tasks run first. The task scheduler for an RTOS is also preemptive. If a higher priority task becomes ready to run, it will immediately pre-empt a lower priority running task. This is required for real-time applications. Finally, the RTOS must be event driven. The RTOS has the capability to respond to external events such as interrupts from the environment. The RTOS can also respond to internal events if required. Scheduler Jargon Multitasking jargon is often confusing as there are so many different strategies and techniques for multiplexing the processor. The key differences among the various strategies revolve around how a task loses control and how it gains control of the processor. While these are separate design decisions (for the RTOS designer), they are often treated as being implicitly linked in marketing literature and casual conversation. Scheduling strategies viewed by how tasks lose control: • Only by voluntary surrender. This style is called cooperative multitasking. For a task to lose control of the processor, the task must voluntarily call the RTOS. These systems continue to multitask only so long as all the tasks continue to share graciously. • Only after they've finished their work. Called run to completion. To be practical, this style requires that all tasks be relatively short duration. • Whenever the scheduler says so. Called preemptive. In this style the RTOS scheduler can interrupt a task at any time. Preemptive schedulers are generally more able to meet specific timing requirements than others. (Notice that if the scheduler "says so" at regular fixed intervals, then this style is called time slicing.) Scheduling strategies viewed by how tasks gain control: • By being next in line. A simple FIFO task queue. Sometimes called round-robin. Very uncommon. • By waiting for its turn in a fixed-rotation. If the cycle is only allowed to restart at specific fixed intervals, it's called a rate cyclic scheduler. • By waiting a specific amount of time. A very literal form of multiplexing in which each ready to execute task is given the processor for a fixed-quantum of time. If the tasks are processed in FIFO order, this style is called a round-robin scheduler. If the tasks are selected using some other scheme it's considered a time-slicing scheduler. • By having a higher priority than any other task wanting the processor. A priority-based or “prioritised” scheduler Not all of these combinations make sense, but even so, it's important to understand that task interruption and task selection are separate mechanisms. Certain combinations are so common (e.g., preemptive prioritised), that one trait (e.g., prioritised) is often misconstrued to imply the other (e.g., 12 preemptive). In fact, it is perfectly reasonable to have a prioritised, non-preemptive (e.g. run to completion) scheduler. For technical reasons, prioritised-preemptive schedulers are the most frequently used in RTOSs. The scheduler is a central part of the kernel. It executes periodically and whenever the state of a thread changes. A single-task system does not really need a scheduler since there is no competition for the processor. Multitasking implies scheduling because there are multiple tasks competing for the processor. A scheduler must run often enough to monitor the usage of the CPU by the tasks. In most real-time systems, the scheduler is invoked at regular intervals. This invocation is usually the result of a periodic timer interrupt. The period in which this interrupt is invoked is called the tick size or the system "heartbeat." At each clock interrupt the RTOS updates the state of the system by analysing task execution budgets and making decisions as to which task should have access to the system CPU. Scheduling Policies in Real-Time Systems There are several approaches to scheduling tasks in real-time systems. These fall into two general categories, fixed or static priority scheduling policies and dynamic priority scheduling policies. Fixed-priority scheduling algorithms do not modify a job's priority while the task is running. The task itself is allowed to modify its own priority. This approach requires very little support code in the scheduler to implement this functionality. The scheduler is fast and predictable with this approach. The scheduling is mostly done offline (before the system runs). This requires the system designer to know the task set a-priori (ahead of time) and is not suitable for tasks that are created dynamically during run time. The priority of the task set must be determined beforehand and cannot change when the system runs unless the task itself changes its own priority. Dynamic scheduling algorithms allow a scheduler to modify a job's priority based on one of several scheduling algorithms or policies. This is a more complicated approach and requires more code in the scheduler to implement. This leads to more overhead in managing a task set in a system because the scheduler must now spend more time dynamically sorting through the system task set and prioritising tasks for execution based on the scheduling policy. This leads to non-determinism, which is not favorable, especially for hard real-time systems. Dynamic scheduling algorithms are online scheduling algorithms. The scheduling policy is applied to the task set during the execution of the system. The active task set changes dynamically as the system runs. The priority of the tasks can also change dynamically. Real Time Scheduling Policies 13 Rate Monotonic - (RMS) is an approach that is used to assign task priority for a pre-emptive system in such a way that the correct execution can be guaranteed. It assumes that the task priorities are fixed for a given set of tasks and are not dynamically changed during execution.. It assumes there are sufficient task priority levels for the task set and that the tasks are periodic. The key to this scheme is based on the fact that tasks with shorter execution periods are given the highest priority. This means that the more frequently executing tasks can pre-empt the slower periodic tasks so that they can meet their deadlines Figure 1 shows how this policy works. In the diagrams, events that start a task are shown as lines that cross the horizontal time line and tasks are shown as rectangles whose length determines their execution time. Example 1 shows a single periodic task where the task t is executed with a periodicity of time t. The second example adds a second task S where its periodicity is longer than that of task t. The task priority shown is with task S having highest priority. In this case, the RMS policy has not been followed because the longest task has been given a higher priority than the shortest task. However, in this case the system works fine because of the timing of the tasks periods. 14 Example 3 shows the problems if the priority is changed and the periodicity for task S approaches that of task t.. When t3 occurs, task t is activated and starts to run. It does not complete because S2 occurs and task S is swapped-in due to its higher priority. When task S completes, task t resumes but during its execution, the event t4 occurs and thus task t as failed to meet its task 3 deadline. This could result in missed or corrupted data, for example. When task t completes, it is then reactivated to cope with t4 event. Example 4 shows the same scenario with the task priorities reversed so that task t pre-empts task S. In this case, RMS policy has been followed and the system works fine with both tasks reaching their deadlines. Deadline Monotonic scheduling • Deadline monotonic scheduling (DMS) is a generalisation of the Rate-Monotonic scheduling policy that uses the nearest deadline as the criterion for assigning task priority. Given a set of tasks, the one with the nearest deadline is given the highest priority, hence, the shorter this (fixed) deadline, the higher the priority. • This means that the scheduling or designer must know when these deadlines are to take place. Tracking and, in fact, getting this information in the first place can be difficult and this is often the reason behind why deadline scheduling is often second choice when compared to RMS. Examples of RMS vs DMS Scheduling Rate Monotonic Scheduling has shown to be optimal among static priority policies. However, some task sets that aren't schedulable using RMS can be scheduled using dynamic strategies. An example is a task set where the deadline for completing processing is not the task period (the deadline is some time shorter than the task period). In this example, we'll show a task set that can be scheduled under the deadline monotonic priority policy, but not under RMS. Consider the following task set: Using the Deadline Monotonic approach to scheduling, the task execution profile is shown in Figure 1. All tasks meet their respective deadlines using this approach. Figure 1. Example of deadline monotonic scheduling. 15 Now consider the same task set, this time prioritised using the Rate Monotonic approach to scheduling. The task priorities change using the RMA approach, as shown below: Same task set for rate monotonic scheduling The timeline analysis using the RMA scheduling technique is shown in Figure 2. Notice that, using the RMA approach and the deadline constraints defined in the task set, that task 1 is now not schedulable. Although task 1 meets its period, it misses its defined deadline. Figure 2. Same example with rate monotonic scheduling—task misses deadline. Dynamic Scheduling Policies Dynamic scheduling algorithms can be broken into two main classes of algorithms. The first is referred to as a "dynamic planning based approach." This approach is very useful for systems that must dynamically accept new tasks into the system; for example a wireless base station that must accept new calls into the system at a some dynamic rate. This approach combines some of the flexibility of a dynamic approach and some of the predictability of a more static approach. After a task arrives, but before its execution begins, a check is made to determine whether a schedule can be created that can handle the new task as well as the currently executing tasks. Another approach, called the dynamic best effort approach, uses the task deadlines and slack to set the priorities. With this approach, a task could be pre-empted at any time during its execution. So, until the deadline arrives or the task finishes execution, there is no guarantee that a timing constraint can be met. Examples of dynamic best effort algorithms are Earliest Deadline First and Least Slack scheduling. • Earliest deadline first scheduling With this approach, the deadline of a task instance is the absolute point in time by which the instance must complete. The task deadline is computed when the instance is created. The operating system scheduler picks the task with the earliest deadline to run. A task with an earlier deadline preempts a task with a later deadline. If a task set is schedulable, the EDF algorithm results in a schedule that achieves optimal resource utilisation. 16 However, EDF is shown to be unpredictable if the required utilisation exceeds 100%, known as an overload condition. EDF is useful for scheduling aperiodic tasks, since the dynamic priorities of tasks do not depend on the determinism of request periods. • Least slack scheduling Least slack scheduling is also a dynamic priority preemptive policy. The slack of a task instance is the absolute deadline minus the remaining execution time for the instance to complete. The OS scheduler picks the task with the shortest slack to run first. A task with a smaller slack preempts a task with a larger slack. This approach maximizes the minimum lateness of tasks. Scheduling with Task Synchronization Independent tasks have been assumed so far, but this is very limiting. Task interaction is common in almost all applications. Task synchronization requirements introduce a new set of potential problems. Consider the following scenario: A task enters a critical section (it needs exclusive use of a resource such as IO devices or data structures). A higher priority task preempts and wants to use the same resource. The high priority task is then blocked until the lower priority task completes. Because the low priority task could be blocked by other higher priority tasks, this is unbounded. This example of a higher-priority task having to wait for a lower-priority task is call priority inversion. Example: priority inversion An example of priority inversion is shown in Figure 3. Tasklow begins executing and requires the use of a critical section. While in the critical section, a higher priority task, Taskh preempts the lower priority task and begins its execution. During execution, this task requires the use of the same critical resource. Since the resource is already owned by the lower priority task, Taskh must block waiting on the lower priority task to release the resource. Tasklow resumes execution only to be pre-empted by a medium priority task Taskmed. Taskmed does not require the use of the same critical resource and executed to completion. Tasklow resumes execution, finishes the use of the critical resource and is immediately (actually on the next scheduling interval) pre-empted by the higher priority task which executed its critical resource, completes execution and relinquishes control back to the lower priority task to complete. Priority inversion occurs while the higher priority task is waiting for the lower priority task to release the critical resource. Figure 3. Example of priority inversion. 17