Runtime & concurrency
Reveal answer and reasoning
Assign stable resource identities and enforce one acquisition hierarchy inside an encapsulated owner rather than exposing writable balances and synchronization objects to arbitrary callers. Define same-resource and duplicate-identity behavior explicitly. Once the required locks are held, validate inputs and compute checked candidate state before storing all related fields, so a later arithmetic failure cannot leave half the update applied.
Test opposing operations with bounded owned workers, direct final-state expectations, conservation, and rejection without mutation. Inspect other helpers and callbacks for hidden acquisitions that violate the same hierarchy. The wrong design adds nested locks in one method while another code path writes the same fields freely or acquires them in reverse. If persistent data is involved, specify and test its actual transaction and concurrency protocol separately; local object-monitor order does not automatically govern database locks or consistency across processes.
What a strong answer covers
- Encapsulate state and the global acquisition hierarchy.
- Compute valid candidate updates before mutation.
- Test rejection, opposing access, and hidden lock paths.
Common pitfall
Protecting one helper while leaving other mutation and lock-acquisition paths unconstrained.
Follow-up questions
- How would a third resource extend the hierarchy?
- What additional evidence would real persistence require?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.