Metal SharedEvent all-work signals do not serialize short untracked command buffers

[lukstafi]

The standalone probe landed by staging#641 (gh-ocannl-828, benchmarks/runners/ocannl/metal_queue_probe.ml) reproduces Metal_backend's kernel/signal/wait+kernel/signal sequence and observes the two command buffers overlapping fully through the ~1.2 s scheduling transition it measured. That contradicts the runtime comment in arrayjit/lib/metal_backend.ml claiming the sequence serializes back-to-back routines.

Why it matters: repeated routines reuse untracked buffer pools, so if consecutive runs of one routine can overlap on the device, the second run may read or write a buffer the first is still using — a silent same-buffer race, not a timing artifact. The gh-828 worker flagged it as outside that issue's timing scope and did not investigate further.

What a fix touches: audit where the all-work signal is placed relative to the encoder's commit (metal_backend.ml, the stream/event machinery), and add an EXECUTED test whose consecutive runs produce distinguishable values when they overlap (a run that writes its own serial number into a cell the next run reads back before writing), so the invariant is checked rather than commented. test/operations/lifecycle-family placement per AGENTS.md.

Filed by the wave coordinator (2026-09-04 fleet wave) from the staging#641 worker's hand-back.

[lukstafi]

Answer in lukstafi#672: the backend's sequence DOES serialize back-to-back runs, and the gh-828 probe was not reproducing it. encodeWaitForEvent takes effect where it is encoded; the probe's event-chain arm appended the wait to a buffer whose compute pass was already encoded and ended, so it ordered nothing, while Metal_backend.link_proc encodes the wait before creating the compute encoder. The PR adds the executed pin the issue asked for (test/operations/back_to_back_runs: a self-incrementing routine with a ~5 ms spin run 16 times with no host sync must count every run — passes on Metal and cc), moves the probe's wait before the compute pass, and keeps the old shape as a wait-after-kernel arm: at a 150 ms kernel on the M4 Max, event-chain runs at 1.001x of a synced pair and wait-after-kernel at 0.501x.

[lukstafi]

Landed in lukstafi#672 (merge e2c5082). The backend's sequence serializes back-to-back runs; the gh-828 probe's event-chain arm had encoded its wait after the second kernel's compute pass, where encodeWaitForEvent orders nothing, so it measured two unordered buffers rather than the backend. Now in the tree: test/operations/back_to_back_runs (a self-incrementing routine with a multi-millisecond spin run 16 times with no host sync must count every run — passes on cc, Metal, CUDA and HIP), the probe's event-chain arm with the wait before the compute pass (1.001x of a synced pair at 150 ms on the M4 Max) with the old shape kept as wait-after-kernel (0.501x), and the queue-analysis records (the scheduling agent note, queued_batch_ms's rationale) attributing the ~1.2 s transition to unordered buffers.