Content deleted Content added
Rkieferbaum (talk | contribs) m v2.05 - Fix errors for CW project (Link equal to linktext) |
Peter Flass (talk | contribs) →{{anchor|Hard|Firm|Require|Soft}}Criteria for real-time computing: bold hard, firm, and soft |
||
Line 37:
Thus, the goal of a ''hard real-time system'' is to ensure that all deadlines are met, but for ''soft real-time systems'' the goal becomes meeting a certain subset of deadlines in order to optimize some application-specific criteria. The particular criteria optimized depend on the application, but some typical examples include maximizing the number of deadlines met, minimizing the lateness of tasks and maximizing the number of high priority tasks meeting their deadlines.
'''Hard real-time systems''' are used when it is imperative that an event be reacted to within a strict deadline. Such strong guarantees are required of systems for which not reacting in a certain interval of time would cause great loss in some manner, especially damaging the surroundings physically or threatening human lives (although the strict definition is simply that missing the deadline constitutes failure of the system). Some examples of hard real-time systems:
* A [[automobile|car]] [[internal combustion engine|engine]] control system is a hard real-time system because a delayed signal may cause engine failure or damage.
* Medical systems such as heart [[artificial pacemaker|pacemaker]]s. Even though a pacemaker's task is simple, because of the potential risk to human life, medical systems like these are typically required to undergo thorough testing and certification, which in turn requires hard real-time computing in order to offer provable guarantees that a failure is unlikely or impossible.
Line 47:
In the context of [[Computer multitasking|multitasking]] systems the [[scheduling policy]] is normally priority driven ([[Preemptive multitasking|pre-emptive]] schedulers). In some situations, these can guarantee hard real-time performance (for instance if the set of tasks and their priorities is known in advance). There are other hard real-time schedulers such as [[Rate-monotonic scheduling|rate-monotonic]] which is not common in general-purpose systems, as it requires additional information in order to schedule a task: namely a bound or worst-case estimate for how long the task must execute. Specific algorithms for scheduling such hard real-time tasks exist, such as [[Earliest deadline first scheduling|earliest deadline first]], which, ignoring the overhead of [[context switch]]ing, is sufficient for system loads of less than 100%.<ref>Liu, Chang L.; and Layland, James W.; "Scheduling Algorithms for Multiprogramming in a Hard Real-time Environment", ''Journal of the ACM'', 20(1):46-61, January 1973, http://citeseer.ist.psu.edu/liu73scheduling.html</ref> New overlay scheduling systems, such as an [[adaptive partition scheduler]] assist in managing large systems with a mixture of hard real-time and non real-time applications.
'''Firm real-time systems''' are more nebulously defined, and some classifications do not include them, distinguishing only hard and soft real-time systems. Some examples of firm real-time systems:
* The assembly line machine described earlier as ''hard'' real-time could instead be considered ''firm'' real-time. A missed deadline still causes an error which needs to be dealt with: there might be machinery to mark a part as bad or eject it from the assembly line, or the assembly line could be stopped so an operator can correct the problem. However, as long as these errors are infrequent, they may be tolerated.
'''Soft real-time systems''' are typically used to solve issues of concurrent access and the need to keep a number of connected systems up-to-date through changing situations. Some examples of soft real-time systems:
* Software that maintains and updates the flight plans for commercial [[airline]]rs. The flight plans must be kept reasonably current, but they can operate with the latency of a few seconds.
* Live audio-video systems are also usually soft real-time. A frame of audio that's played late may cause a brief audio glitch (and may cause all subsequent audio to be delayed correspondingly, causing a perception that the audio is being played slower than normal), but this may be better than the alternatives of continuing to play silence, static, a previous audio frame, or estimated data. A frame of video that's delayed typically causes even less disruption for viewers. The system can continue to operate and also recover in the future using workload prediction and reconfiguration methodologies.<ref>{{cite journal | title = Real-time reconfiguration for guaranteeing QoS provisioning levels in Grid environments | journal = Future Generation Computer Systems | volume = 25 | issue = 7 | pages = 779–784 | date = July 2009 | doi = 10.1016/j.future.2008.11.001| last1 = Menychtas | first1 = Andreas | last2 = Kyriazis | first2 = Dimosthenis | last3 = Tserpes | first3 = Konstantinos }}</ref>
| |||