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.
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.
| Index | Previous | Next |
|---|
Copyright ©2017, G. Hill Price
Send comments to G. Hill Price