We Found a Memory Ordering Bug in Every Major Browser Engine — Here's the Fix
While building a .NET-to-WebAssembly GPU compute library (SpawnDev.ILGPU), we hit an "impossible" race condition: our multi-worker barrier synchronization worked perfectly with 2 workers but failed...

Source: DEV Community
While building a .NET-to-WebAssembly GPU compute library (SpawnDev.ILGPU), we hit an "impossible" race condition: our multi-worker barrier synchronization worked perfectly with 2 workers but failed catastrophically with 3+. After weeks of isolation, we traced it to a memory ordering bug in Atomics.wait that affects V8 (Chrome/Node.js), SpiderMonkey (Firefox), and ARM devices. We've filed it as Chromium Issue #495679735, built a minimal reproducer with a live demo, and shipped a proven workaround. The Bug in 30 Seconds When 3+ Web Workers synchronize using a generation-counting barrier with Atomics.wait / Atomics.notify: Workers write data to SharedArrayBuffer Workers enter a barrier (atomic arrival counter + generation bump + wait/notify) After the barrier, workers read each other's data Expected: All workers see all other workers' writes after the barrier completes. Actual: Workers whose Atomics.wait returns "not-equal" (because the generation was already bumped before wait was called