Preemptive (OS interrupts and executing process when it sees fit) vs. nonpreemptive (process gives up CPU when it sees fit).
Starvation -- some processes may never get selected for execution. This is usually a property of a particular scheduling scheme. For example, SJF can lead to starvation of long processes if the system is busy and has a continual stream of new short processes. However FCFS can never lead to starvation. Having a scheduling scheme which cannot lead to starvation is considered important.
Process aging -- a mechanism whereby some process increase in priority as they become older. Often used with priority scheduling when low priority processes never get selected due to large numbers of high priority processes.
tau(n+1) = alpha * t(n) + (1 - alpha) * tau(n)where
t(i): actual lenght of ith burst
tau(i): estimated length of ith burst.
By selecting different values of alpha (between 0 and 1), the estimate of the next burst can depend wholely on the size of the last (1) or wholely on an estimate (0). This is really a form of Priority Scheduling, where the priority of a process is based on the estimated size of its next burst. Priorities can be based on many other factors: e.g., purchase price, nature of task (system vs. user).
Hard systems: fly an airplane, control a reactor, control a car, automate data collection.
Soft systems: multimedia (deliver segment of audio or video data fast enough to keep up and appear smooth), games.
Hard real time attempts to guarentee that a process will complete by a specified deadline. And will not admit a new real-time process if it cannot guarentee that it can meet its deadline. This requires the time required for each process be known before it starts. And that no "unexpected" things (at least those which cause existing processes to take more time) happen. Hence no time-sharing, no virtual memory, hence no UNIX.
Many real-time systems have simple OSs: don't want the OS to start additional new processes which might cause some existing process to miss its deadline. Design of system may be such that no new processes can appear when real-time deadlines must be met, and this had nothing to do with scheduling.
Real time systems must give priority to real-time processes, at least as they get close to their deadlines.
For pragmatic reasons, real-time systems usually require some mechanism which allow quick dispatching of any real-time process on the ready queue. Usually OS processes run in a non-preemptive state since these processes may be updating system tables and their interruption could leave these tables in an invalid state. In UNIX, all OS processes are run by the "kernel" and the kernel is nonpremptive. A related problem is that of "priority inversion." This occurs when a high-priority process, for example a real-time process, is blocked waiting for a resource being held by a low-priority process. The standard fix is to have the blocking low-priority process inherit the priority of the higher-priority process.
There is an old story of early multiprocessor British system that would occasionally -- but rarely -- allocate system printer to two processes. It took a long time to discover the cause. It turned out that the OS routime that allocated to line-printer did this by checking a resource table entry to see if the printer was free. If it was, then the entry was changed and the printer "allocated" to the process. If not, process blocked until printer is free. Problem was that sometimes the allocation routine could check table entry, find the printer free, then get interrupted, be moved to end of ready queue, and when it moved to the front of the queue again, it would change the table entry, and allow the process to start printing. But if another process issued the same OS system call before this process got its next time slice, that process would find the table unupdated, and allocate the printer.
But back to real-time issues. Since some OS calls are long running, we may put break points in them where they could be interrupted. Or make the kernel interruptable. But this requires that the kernel be able to lock some data structures when they are being modified. (Above problem would not have occurred if first process could have locked the resource table). This causes priority problems. See text for solution.
| Index | Previous | Next |
|---|
Copyright ©2004, G. Hill Price
Send comments to G. Hill Price