mirror of
https://github.com/vercel-labs/scriptc.git
synced 2026-11-04 08:04:37 +08:00
Chris Tate
feb9877f1a
In a program with workers, every element of a view that may be backed by a SharedArrayBuffer was read and written with relaxed atomics, so that a loop which reads one element again sees another thread's write. LLVM does not vectorize loops with atomic accesses: a byte loop over a shared Uint8Array ran at 8.5 ns per element in a program with workers and 0.14 ns in one without. In a counted loop that polls for cancellation between blocks of iterations, an element read or written at the loop's counter, outside any loop nested in the body, is now a plain load or store, like a thread-owned view's. The counter steps by a nonzero constant and the body does not assign it, so every iteration reaches a different element and no read is merged across iterations or moved out of the loop. Within one iteration, a racing write from another thread can be seen or missed, the documented gap of non-atomic shared accesses. Other accesses, Float16 elements and Atomics keep their atomic paths. Corpus 8332 runs these loops over shared views of each element type on a worker and the main thread, and matches Node's output.