etc.
Hard Real-Time Systems
- Principles
-
- Guaranteed performance
- Reliability
- Efficiency
- Best effort principles, as much as possible
- Resources
-
-
- Only those that can provide guaranteed service times
-
- no virtual memory
- no internet
- Often constrained further by data rate
API
- 1. A priori knowledge of
-
- Applications to be executed
- Application resource needs (usually based on worst-case
assumptions)
-
2. This information may be implicit or explicit
-
- Implicit - System designer knows this information and designs the
system appropriately
- Explicit - Applications specify the information
-
Approaches
-
- Specialization
- Applications specify deadlines
-
- Predictable scheduling algorithms
-
- Earliest deadline first
- Rate monotonic
- Least laxity first
- ...
-
- Predictable and carefully measured applications
-
- Must be able to specify worst-case execution time
- Job admission control
- Detailed a priori knowledge of applications, data, etc.
- Low level interfaces for high degree of control
- Predictable system services
- Limited use of unpredictable services (e.g., internet)
-
Examples
-
- VxWorks
- RTOS
- pSOS
- Spring
- Real-time Linux (sort of)
- NT & Solaris (in a very limited fashion)
- ...
- Applications
-
- Flight control
- Medical devices
- Robotics
- Automobiles
- ...
- Plusses
-
- Guaranteed performance
- Predictable
- Less error-prone (mostly because they don't do as much)
- More secure (for the same reason)
- Usually faster (ditto)
- Issues
-
- Job admission
- Priority inversion
- Inflexibility
-
- Often engineered for a single job
- Don't do anything else, well or otherwise
- Need a priori information
- Worst-case assumptions lead to very poor resource utilization
- Can't handle mix of real-time and non-real-time applications
- Enforce absolute guarantees - can't provide anything in between
Soft Real-Time
- Principles
-
- All principles from both general purpose and hard real-time except
- Failure to meet a deadline is considered neither application
nor system failure
- It's just considered less "good"
- What that means is poorly defined and varies from system to system
- Resources
-
- Primarily CPU and network
- Everything else, to a lesser degree
API
1. Applications try to run and unimportant ones are dumped
(collaborative load shedding) or simply don't run non-critical
parts (SPRING)
2. Applications try to run and get a proportional share of the
resources (SMART)
3. Applications explicitly reserve the resources they need (RT-Mach
w/Reserves, Rialto) on a FCFS basis
4. Applications specify a range of acceptable resource allocations,
and the system dynamically determines how much they get (MMOSS)
5. Applications specify cost-benefit functions and the system
determines how much resources they should get, and when, based on
this function (Jensen, CMU, DQM).