Part 7 answers: In what order do results become visible?

Concurrency lets transactions overtake each other. Software, and other hardware, often depends on order: data before the flag that says it is ready. Ordering rules say which overtakes are allowed and who pays to prevent the rest.

This part covers why order matters, ordering scopes, the point of serialisation, what an acknowledgement promises, fences, ordering tables, relaxed ordering, same-address hazards, interrupts and data, consistency models and ordering across bridges.

After this part you can

• Explain the data-then-flag problem and the rule that prevents it.

• Read a passing-rules table and give the reason for each cell.

• Find the broken ordering rule in a bridge.

Warm-up: three questions from Part 6

Answer each in your head before opening it. If two or more feel shaky, revisit Part 6: Concurrency and Performance first.

Lessons

Every lesson in this part is ready. Work through them in order: each one sets up the problem the next one solves.

Where other courses go deeper

This course teaches why protocols are designed the way they are. These lessons show how to build or sign off the same ideas, so this part links to them instead of repeating them.

• Architecture: Memory Ordering Models

Related topics

• Course hub

• Previous: Part 6 · Concurrency and Performance

• Next: Part 8 · Sharing and Arbitration