SharedArrayBuffer
Slap yourself if
You think SharedArrayBuffer is just a faster postMessage or assume Atomics magically make your code thread-safe.
Why this exists
Because SharedArrayBuffer looks like a performance feature but is actually a memory model and security decision that can destabilize your app if you treat it casually.
Mental model
SharedArrayBuffer is shared memory with no safety rails. Atomics give ordering, not correctness. You are opting into low-level concurrency in a platform designed to avoid it.
- A SharedArrayBuffer allocates memory visible to multiple agents.
- Multiple threads can read and write the same bytes concurrently.
- Without Atomics, reads and writes can be torn or reordered.
- With Atomics, ordering and visibility are enforced — not intent.
- Assuming atomic operations prevent logical races.
- Sharing complex data structures without synchronization discipline.
- Forgetting that non-atomic reads are still allowed.
- Enabling SharedArrayBuffer without understanding isolation requirements.
SharedArrayBuffer enables shared memory between threads, requiring explicit synchronization via Atomics and introducing a real memory model with security implications.
- Calls it shared state with workers, casually.
- Assumes Atomics equals thread safety.
- Ignores Spectre-related constraints.
- Cannot explain why it was disabled historically.
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.