It may be served earlier than other eligible requests. It may not bypass the protocol steps needed for permission or current data. Take an independent warm snapshot (X started at 0, then C0 acquired M and stored 1): C0 M / 1, C1 I / -, H exclusive(C0), memory = 0. C0 holds the newest X. Marking C1's GetM urgent does not let H use memory = 0 as its current value: H must still forward to C0.
Start with the safety-preserving resource design from the deadlock lesson: accepted transactions have protected completion capacity. Add a scheduling rule only after that structure is valid. A response priority bit cannot help if the response has no receive storage, and a separate queue cannot help if its consumer is permanently blocked.
Proposal | Evaluation | Needed constraint |
|---|---|---|
Give urgent GetM earlier admission | A performance policy | Retain waiting work and prevent unbounded bypass under the intended fairness contract. |
Skip an ordinary core's Inv-Ack for an urgent writer | Unsafe | Every required conflicting permission must still be resolved. |
Reserve response credits independent of new requests | A structural progress aid | Route, receiver storage and service must all support the reservation. |
Let urgent requests consume the last completion buffer | Potential resource-cycle regression | Admission must preserve capacity needed by accepted work. |
Prioritise responses with no service for requests | May starve request admission | Guarantee requests some service, or cap how long responses can hold requests back. |
Admitting an urgent request early does not make it finish early. From the snapshot above, C1's urgent GetM is admitted at H at once. Its completion still needs C0 to handle the Fwd-GetM and send Data(X=1). If the Fwd and Data travel in a low-priority class, or wait at C0 behind C0's own low-priority requests, the urgent transaction runs at the speed of its slowest dependent leg. The priority was spent on one leg out of three or four.
General remedy | What it does |
|---|---|
Forwards and responses inherit the requester's priority | The Fwd-GetM to C0 and C0's Data carry C1's urgent priority, so no leg of the transaction runs at low priority. |
Completion classes are served ahead of requests at every node | Fwd, Inv, Inv-Ack, Data and Put-Ack never wait behind new requests, whatever the requester's priority. |
Both remedies rest on one reason: completion messages release resources held by accepted transactions (H's pending entry, the requester's miss entry, buffers holding dirty data). Starving them leaves those resources held, and every class, urgent ones included, then waits for a free entry. Which remedy fits is a design choice; these are general guidelines, not a vendor's rules.
An Inv-Ack completes a transaction H has already accepted: until it arrives, H keeps that pending entry and blocks every later request for the line. A high-priority GetM for the same line therefore waits for the very Inv-Ack it is blocking, and pending entries filled by stalled transactions stop admission of all other requests too. Blocking completion traffic turns priority into a resource cycle or starvation for every class.
For example, choose weighted service among admitted request classes with nonzero service for each, while completion traffic has reserved capacity and fair service. This is a design direction, not a universal recipe. A minimum share among eligible requests requires that requests actually remain eligible. A finite latency target also needs bounds on competitors, transaction service, route delays and consumer backpressure.
Measure admission wait separately from active-transaction time. Include worst observed and tail waits for each class, plus reasons a request became ineligible. A good average over high-priority traffic can conceal a low-priority queue that never drains. A finite measurement cannot establish eventual service for all future executions.
No. X = 1 must remain protected through whichever source, response and accepted buffer currently carries responsibility. Urgency does not change that obligation.