For each lesson, answer the opening question before memorising its terms. A coherence state is useful only when you can say which operations it permits and how its data relates to other copies.
Part of the lesson | What it gives you | What to do with it |
|---|---|---|
Opening question | The problem the lesson solves, often a wrong intuition to test. | Answer it in one or two sentences before reading on. |
Mechanism | The rule and the hardware structure that enforces it, stated outright. | Say which resource, record or message makes the rule true. |
Worked case | One example on the course model: protocol named, warm-up stated, X starting at 0. | Trace it yourself before reading the explanation. |
Diagram and table | A numbered message sequence and a state/value table that agree row for row; state machines and dependency graphs where they help. | Cover the later rows and predict them. Check the newest-data column at every step. |
Python that runs | A small standard-library program that asserts the lesson's claim, including the failure case, and prints one PASS line. | Run it, then change one rule and watch the check fail. |
Pitfall and interview angle | The common mistake and how an interviewer probes the topic. | Explain the mistake in your own words. |
Check-yourself | A question with the reasoning in the answer. | Commit to an answer before opening it. |
Read the course model, including the delivery and serialization assumptions.
Read the example once for its purpose, then trace every numbered message on paper.
Cover the final rows of the snapshot table and predict the next cache permissions and values.
Answer the check-yourself, compare the reasoning, and correct your own trace.
Use the related lesson links to continue. Revisit the glossary when a term is doing work you cannot explain, and the revision sheet at the end of each part.
View | Question to ask |
|---|---|
Prose | What problem is this transaction solving? |
Message sequence | Who sends what to whom, and when is it received? |
State/value table | Who may use this value after that event? Is memory current? |
State machine | Which event triggers an action, and what is waiting in a transient state? |
Exercise | Can I reconstruct the mechanism, not just recognise its name? |
Every lesson follows the conventions listed once in the course model: the initial state, how arrows and table rows line up, the directory notation, the transient-state names, who collects acknowledgements, and what the base traces deliberately leave out. Lessons do not repeat those caveats. Each lesson names its protocol (MSI, MESI or MOESI) and any warm-up prefix it starts from.
Read it once before Part 1, and again before Part 4, where races test every assumption it states.
When a lesson adds something (a third core, a finite buffer, a power state, a cluster), the course model's table of named extensions says which lesson introduced it. Everything not named stays as the base model says.
When a trace seems to contradict another lesson, check the protocol, the acknowledgement collector and the warm-up first. Those three explain most apparent disagreements.
A complete Python example uses only the standard library, is deterministic, asserts its expected relationships and ends with one PASS line if those assertions hold. Copy it into a file and run it with Python 3. PASS establishes only the checks in that program. It does not prove every interleaving or validate hardware. A text trace or a block marked not-run explains an example rather than executing one. Real-protocol names (ACE, CHI, TileLink) appear only in Part 8 and in lessons that name the specification and revision; everywhere else the course uses its own generic messages.
Part 13 holds a 50-question bank in five lessons of ten: fundamentals, transactions and races, ordering, verification and debug, and architecture. Every question has the same six fields: what the interviewer is testing, a weak answer, a strong answer, follow-ups, the common trap, and the lesson that teaches it.
Learn the four steps of The Answer Framework: assumption, mechanism, trade-off, evidence.
Read only the question, cover the table and answer aloud or on paper in about two minutes.
Compare with the strong answer and score yourself 0 to 4 with the Grading Rubric.
Where you missed a step, read the lesson in the "Taught in" row, then try the follow-ups.
Repeat the questions a week later in a different order.
The capstone is the course's single piece of work to show. You write a runnable model of a three-core MESI directory protocol with a checker that judges every value after every event, switch on three planted defects (a lost invalidation, a stale writeback and a buffer deadlock), find each with the check meant for it, fix them, compare MESI and MOESI traffic on the same trace, and write a design memo. It needs Parts 2 to 5 and the Part 11 reference model, and takes about 7 to 9 hours if you write your own model, or about 2 hours to read and run the worked solution (estimates). Start with the Capstone Brief, which states the deliverables and how they are graded.
Not necessarily. Some protocols send acknowledgements to the requester, which counts them. Within one lesson, though, the diagram, table and prose must agree on who waits for the acknowledgements, and nobody may grant or use M until all have arrived.