Interruptive arbitration cuts off feedback; queued arbitration lets it finish first
Aliases: interruptive · queued · preemption
What it is
Interruptive arbitration cuts off current feedback to play the new event; queued arbitration places the new event behind it. The two suit different urgency profiles: situations needing immediate response favor interruption, while those that can wait favor queueing.
Why it happens
The costs differ. Interruption guarantees immediacy for the urgent event but breaks the integrity of the feedback in progress, and users may lose context; queueing preserves the existing feedback's completeness but delays the urgent event until it ends. The choice therefore turns on which cost is larger: interrupt when the loss from delay exceeds the loss from cutting off, queue when the reverse holds. Both costs vary with event importance, so the policy should follow event level rather than being fixed globally.
Studying it
Compare the two strategies across event combinations: set up a scenario where a high-priority event arrives during low-priority feedback and apply interruption versus queueing, measuring the high-priority event's response latency, recovery of the interrupted content, and user confusion. Variables include the level gap, current feedback duration, and availability of recovery mechanisms.
Where it stops holding
When interrupted feedback can be fully recovered, interruption's cost drops markedly and its range of applicability widens. When the higher-priority event is not genuinely urgent—merely ranked above another—interruption causes needless disruption and queueing is better. If users cannot tell whether interrupted content will resume, either strategy needs a companion status cue.
Applying it
- Decide between interruptive and queued per event level rather than fixing one policy globally.
- When interrupting, provide a recovery path for the interrupted content to limit context loss.
- When queueing, indicate queue state so users know more events are waiting.
- Verification: in mixed-priority scenarios, measure response latency for high-priority events and user confusion, confirming the chosen strategy's cost is acceptable.
Related
- Within the group: D5.06.4 Arbitration must handle queueing and dropping among simultaneous events · D5.06.7 Users should be able to override the default arbitration for a situation
- Adjacent: D2.10.2 Higher-priority alarms should interrupt lower-priority playback · D5.06.3 Priority follows consequence level, not channel capability
- Search terms:
interruptive arbitration·queued playback·preemption cost
Cards in the same group
- D5.06.1Simultaneous multichannel output needs arbitration rules
- D5.06.2The same event should not be fully repeated on every channel
- D5.06.3Priority follows consequence level, not channel capability
- D5.06.4Arbitration must handle queueing and dropping among simultaneous events
- D5.06.6Cross-application arbitration usually belongs to the system layer
- D5.06.7Users should be able to override the default arbitration for a situation