An emergency-management office runs six parallel subagents, each producing a written assessment for one hazard category. The team must ensure that concurrent writes cannot destroy one another's output. What is the correct design?
Select an answer to reveal the explanation.
Short Explanation
The cheapest concurrency control is not needing any. Give each hazard subagent its own file name at launch—flood, wildfire, and so on—and there is nothing left to collide over.
Full Explanation
Parallel subagents share no state and cannot coordinate with one another mid-run, so any design that has them contend for a single resource is relying on timing luck. The durable fix is to remove the contention rather than manage it: partition the write surface so concurrency never arises.
Assigning each of the six hazard subagents a disjoint output path in its launch prompt means no two agents ever touch the same file. The parent knows all six paths in advance because it issued them, so the merge is a deterministic read of six known files, and a missing or truncated file identifies exactly which hazard category needs a re-run.
Six concurrent appenders to one file can interleave partial content, with nothing guaranteeing a whole assessment stays contiguous; leaning on last-writer-wins is an explicit acceptance of data loss, since five of six assessments would be overwritten; read-then-merge-then-write is the textbook lost-update race, because two agents that read the same starting content before either writes will each produce a version missing the other's work.
Exam caveat: disjoint paths solve write collisions but not completeness—the parent still needs a rule for what to do when an expected file is absent. Operational check: after the fan-out, assert that all six paths exist and are non-empty before merging, and treat any gap as a re-run signal rather than publishing a partial assessment set.