Robert Allan JamesandClaude Opus 5.5
02c4c7e620
- Ruling (Captain Bob): per-slot locks, not "own path needs no lock" -- a lock only on the cross-slot side can't exclude an unlocked owner (Hermes release evicting a sender's cell while the sender admits). FABRIC-3.10.0 §3.6 amended. - StadiumVMQuota.lock covers the slot's lists, reservoir, consumed, word row and its cells. Word dispatch holds only its own slot lock for the whole dispatch (*_in_slot forms); peek-then-pull is one step. - g_lock_stadium: grant slot allocation (new slot published with release in_use) and the shared block table (ruled: the one shared-lock Stadium path). Taken before a slot lock. - Bitmap bytes set/cleared atomically (8 cells, possibly 8 slots). - Cross-slot writers moved under the owner's lock: Hermes decay (stadium_cell_decay), Hermes release ledger (stadium_evict_credit), session pin (stadium_cell_set_pin). stadium_conserved() one hold. - Word and block cell lookups check the cell is still this slot's. - Probe (removed), identical on all three ISAs: 10,746,599 of 10,746,616 word dispatches took exactly one lock (own slot), the 17 others all row growths; every live VM conserved; Hermes audit failures 0. - Findings reported: births/USE run a VM's words while another VM is the core's current VM (MC-3 claim must cover it); quota slots never released; owner admission can evict a live message cell (latent, 0). - Standard sequence on amd64/aarch64/riscv64: dict_hash set and G byte-identical, MINT/WIREBIND/USE ok, conservation true, 0 idle growth. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
0 B
0 B
The file is empty.