Violation events for FRT subscribers/requests
FRT subscribers and requests should react to timing violations as soon as they occur, similar to their HRT pendants.
While HRT violations always result in the execution of a defined panic callback, FRT violations should signal the corresponding node thread (or emit an according event; to be discussed) and execute a custom (optional) callback function. This would allow recoverable incidents, which do not necessarily have to result in a system panic if a stable state can be reestablished in time.
This modification would actually change the definition of FRT slightly:
- NRT
- No real-time constraints at all
- Usability is always 1.
- SRT
- Real-time constraints defined by custom usability function callback.
- Usability can be assessed whenever the according thread is scheduled again (= arbitrary delay).
- FRT
- Real-Time constraints are defined by latency, jitter and rate parameters.
- Timing violations are detected as soon as they occur (via timers) and execute a customizable reaction callback.
- Timing violations may be recoverable (= no system panic).
- HRT
- Like FRT, but timing violations are severe incidents (not recoverable), resulting in a system panic.
- A system-wide defined panic callback is executed.
A further implication for services would be, that the request queue should be divided into four instead of three segments:
- HRT requests (earliest deadline first)
- FRT requests (earliest deadline first)
- SRT (first in first out)
- NRT (first in first out)
Edited by Thomas Schöpping