Prove the atomic queue fast path has a safe memory order
A lock-free experiment publishes a slot index before all job fields are visible, producing rare partially initialized reads on a weakly ordered target.
- Focused work estimate
- 6h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Atomics · Memory models · Model checking
Estimated field mix
- Systems programming65%
- Performance engineering35%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional image-indexing utility runs CPU-only synthetic jobs through a Rust worker pool. Its prototype loses wakeups, blocks shutdown, and treats cancellation as completion. Build a local library and deterministic concurrency harness; image content, GPU work, and production deployment are excluded.
Setup prerequisites
- Mutexes and condition variables
- Atomics
- Thread lifecycle
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- Every atomic operation has a stated synchronization role
- Publication makes complete job data visible before claim
- Wraparound cannot confuse a reused slot with an older generation
Implementation constraints
- Prefer the mutex implementation unless measured need and model checking justify the atomic path.
Verification to include
- Model-check bounded producers, consumers, and slot reuse.
- Weaken the publication ordering in a mutation and ensure the model detects an invalid read.
Deliverables
- Memory-order argument, model, and comparison with mutex path
Rollout and recovery
Keep the atomic implementation disabled unless correctness and workload benefit are both demonstrated.
Value of the work
For the engineer: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing.
For the team: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.