Runtime & concurrency
Reveal answer and reasoning
If every operation acquires the same resources in one stable global order, the opposite-direction two-resource cycle can be excluded from that protocol. Transfer chooses the lower account identifier first regardless of which account sends the amount. That ordering is about resource acquisition, not the direction of the domain action. Stable resource identity and participation by every access path are required assumptions.
A common wrong answer reverses lock order with transfer direction or declares the whole application deadlock-free after inspecting one helper. Another method, callback, unrelated lock, or blocking dependency can introduce a different cycle. Public data writes can also bypass the protected invariant entirely. The lesson therefore provides bounded opposing-worker evidence and a focused ordering argument, not a complete account domain model, database transaction, or proof of fairness.
Encapsulation and failure-before-mutation arithmetic remain separate design responsibilities.
What a strong answer covers
- Acquire resources by a stable order, not action direction.
- Every participating path must honor the protocol.
- Other locks and callbacks can introduce different cycles.
Common pitfall
Calling a local lock-order rule a proof that an entire application cannot deadlock.
Follow-up questions
- What if identifiers are duplicated or mutable?
- Why should unknown callbacks be avoided while holding locks?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.