A senior engineer is judged less on knowing MESI than on what they do with a proposal: find the races it creates, ask for the evidence that would settle it, and write the decision down so the team can act. This topic turns the mechanisms of Parts 3 to 12 into that routine. Every example uses the course model and every number is illustrative and computed, not measured.
Lesson | After it you can... |
|---|---|
Diff a state table, list each existing message that can now reach a new state, and turn the gaps into findings. | |
Run a coherence review in which every item is answered by a named piece of evidence. | |
Write a one-to-two page memo whose recommendation follows from computed numbers, and say when it would flip. | |
Answer five classic senior trade-offs with the numbers or conditions that decide them. |
Suggested order: the protocol-change review first (it is the hardest skill), then the checklist that generalises it, then the memo that records a decision, then the trade-off questions as practice. The answer framework of the previous topic (assumption, mechanism, trade-off, evidence) is the spine of all four.
No. Removing a message removes information that some controller relied on. In the course model, dropping PutE means H can still record a cache as exclusive after that cache has forgotten the line, so forwards can now reach a cache in I, IS^D or IM^D. Every removed message has to be reviewed for which states and events it used to rule out.