C0 has asked to write, but C1 has not yet invalidated its copy. What state should C0 be in? Calling it M would grant permission too early; calling it an ordinary S would hide unfinished work. A transient state records that work and the conditions still required for completion. Prerequisite: the stable MSI and MESI permissions.
The names follow the Primer, second edition: XY^D means 'was X, wants Y, waiting for Data', and XY^AD adds 'waiting for acks'. Because this course collects Inv-Acks at H, the requester only ever waits for Data. The official gem5 MESI Two Level controller description uses the plain names IS, IM and SM for comparable states; our messages follow the course model, not gem5's opcodes.
Course name (acks at H) | Primer name with acks at requester | What is retained? | What is missing? | Access rule |
|---|---|---|---|---|
IS^D | IS^D | No usable value | Value and read permission | Loads and stores stall |
IM^D | IM^AD | No usable value | Value and exclusive permission | Loads and stores stall |
SM^D | SM^AD | Current shared value | H's grant, sent after H collects the Inv-Acks | Loads hit, stores stall |
SM^D can also lose: if another writer's GetM was serialized first, C0 receives an Inv while waiting, answers it, and becomes IM^D, now needing the data as well as permission. That race is taught in Part 4.
The shared upgrade with one required acknowledgement (GetM, Inv, Inv-Ack collected at H, then permission-only Data) is traced row by row in Epochs and Serialization. Use the same C0 and C1 roles and step numbers, and read each row for its pending work rather than its messages:
Step in that trace | C0 retains | C0 still lacks | H's pending entry tracks |
|---|---|---|---|
1. GetM at H | S copy of 0, loads hit | Exclusive permission | Requester C0, acks 0/1 |
2. Inv at C1 | S copy of 0, loads hit | Exclusive permission | Unchanged: no message reached H, C1 still listed |
3. Inv-Ack at H | S copy of 0, loads hit | Exclusive permission (grant not yet sent) | acks 1/1, C1 removed, ready to grant |
4. Data at C0 | Value and M permission | Nothing: C0 is stable M | Kept until the (assumed) grant-delivered row |
C0 stays in SM^D through steps 1 to 3 and is stable M only at step 4; H's entry settles at exclusive(C0) one row later, under the course model's grant-delivery assumption. Four serial legs, because acks go to H. The Primer's design instead sends acks to the requester with an ack count in Data, three legs; both are legal, and then C0 waits in SM^AD for Data and every ack.
H needs the requester C0, the outstanding acknowledgement count, and the source of the data; C0 needs its requested permission and retained line. A state label without these obligations cannot explain completion. If data and permission arrived separately in a different model, both conditions would need tracking; do not infer one from the arrival of the other.
Stable describes a settled permission condition; it does not mean no future event can change it. Transient describes outstanding protocol work; it does not promise a fixed number of cycles. Eventual delivery, eventual controller service and available buffering would all be needed to argue that this pending request finishes. The snapshots establish permission safety for this trace, not a general progress proof.
Here that is unsafe only because the acks go to H: C0 would receive Data, treat it as the grant and store while C1 might still hold S, since no FIFO order exists between Data and Inv. With an ack count in Data and acks sent to the requester (the Primer's design), sending Data early is legal: C0 waits in SM^AD until all acks arrive, so the writer-plus-reader overlap still cannot occur.