Arbitration must handle queueing and dropping among simultaneous events

What it is

Arbitration must state how simultaneous events queue and how they are dropped. Defining priority without queue and drop rules produces hidden behavior: an unbounded queue delays everything, or the system drops events arbitrarily under pressure. Either way, the promise of priority is broken.

Why it happens

Queue and drop rules address capacity. Only so many events can be processed per unit time, so beyond that, events must wait or be abandoned. The queue policy decides which events wait and how long; the drop policy decides when waiting stops. Without a queue bound, a critical event can sit behind many low-priority ones and be delayed far beyond expectation; without a drop rule, the system under pressure may discard a critical event rather than the most expendable one. The rules must also say whether dropped events are recorded, or users never learn something occurred.

Studying it

Run high-concurrency stress tests: fire many events beyond processing capacity and record the latency distribution for critical events, which event types are dropped, and whether users notice losses. Variables include concurrency intensity, queue bound, and drop criteria. Include whether critical events are dropped, since that is the core test of the priority promise.

Where it stops holding

When event density stays well below capacity, queue and drop rules are rarely exercised and their details do not affect experience. Under low load, users tolerate longer queueing. If the system can surface queue state, users accept some delay, so queue rules should be designed together with status indication.

Applying it

• Bound the queue and specify what happens when the bound is reached.
• State drop criteria explicitly so critical events are not the first discarded when the queue fills.
• Record dropped events so users can learn after the fact what occurred.
• Verification: under over-capacity concurrency, measure critical-event latency and drops and confirm the priority promise holds under pressure.

Related

• Within the group: D5.06.3 Priority follows consequence level, not channel capability · D5.06.5 Interruptive versus queued arbitration
• Adjacent: D2.10.3 Arbitration must tell the user that more alarms are queued · D5.06.6 Cross-application arbitration usually belongs to the system layer
• Search terms: queue policy · drop policy · backpressure