All categories/Code and debugging
Writing code and tests · Level Advanced · Coding Coding Concurrency
Concurrency: define the critical section
Concurrent requests overwrite each other on the same row.
Prompt
Three defaults: define the input-output contract, then the error branches, then the happy path. An implementation without error handling is not finished.
Task: Concurrent requests overwrite each other on the same row.
[Before you start, do three things]
1. Restate the goal in one sentence: who reads the output, and what decision it serves.
2. If I have not given you the following, ask me. Do not assume:
- where the read-modify-write happens
- multiple instances
- acceptable conflict policy
3. Say how you plan to do it (at most 5 steps) and wait for my go-ahead.
[Go through each of these]
- draw the critical section: which lines must be atomic
- three options: pessimistic lock, optimistic version, queue, with cost
- state user-visible behaviour on conflict
- give a concurrency test method
[Process]
1. State the contract: inputs, outputs, errors, side effects
2. List every error branch and boundary first
3. Then the happy path, one responsibility per function
4. Test key paths: one normal, two failure cases
5. State when this code would fail
[Output]
Contract, errors, happy path, tests, failure conditions.
[Do not]
- Never ignore an error return
- Never swallow exceptions
- No magic numbers; name them
- Do not log-and-continue instead of returning an errorWhat to state before it starts
Leave these unsaid and the model fills them with an assumption. Most 'wrong answers' start here.
- where the read-modify-write happens
- multiple instances
- acceptable conflict policy
Go through each of these
Where this kind of work most often goes wrong. Already in the prompt, so you do not have to remember it.
- draw the critical section: which lines must be atomic
- three options: pessimistic lock, optimistic version, queue, with cost
- state user-visible behaviour on conflict
- give a concurrency test method