SharedArrayBuffer: True Shared Memory for JS Threads
SharedArrayBuffer is a shared whiteboard for JS threads, letting them access the same memory without slow data copies. It's used for high-performance parallel tasks. The footgun: without Atomics to coordinate, you'll get race conditions and corrupted data.
Why it exists
Standard Web Workers communicate by passing messages, which involves serializing and copying data. This is prohibitively slow for large datasets. SharedArrayBuffer was created to allow multiple threads to access the exact same block of memory, eliminating the copy overhead for high-performance parallel computing.
The mental model
Think of standard message passing as emailing a document to a coworker. They get a copy, and their edits don't affect your original. A SharedArrayBuffer is like a shared Google Doc. Both of you can see and edit the same document in real-time, which is faster but introduces the risk of overwriting each other's work if you don't coordinate.
How it works
You create a SharedArrayBuffer in one thread and send it to another (e.g., a Web Worker) via postMessage. The browser doesn't copy the data; it just passes a reference. Both threads now point to the same memory. To prevent chaos from simultaneous reads and writes (race conditions), you must use the static methods on the global Atomics object. Operations like Atomics.add(), Atomics.load(), and Atomics.compareExchange() guarantee that a read or write operation finishes completely before another thread can touch the same memory location, ensuring predictable outcomes.
When to use it
Use SharedArrayBuffer when multiple threads, like Web Workers, need to frequently read and update a large, shared dataset. This is ideal for high-performance applications such as in-browser games, scientific simulations, audio/video processing, or any task that can be heavily parallelized across CPU cores.
When not to use it
Avoid this for simple communication or small data. The complexity of managing memory with Atomics is overkill if the performance cost of copying data is negligible. If your threads don't need to modify the same data concurrently, standard message passing is safer and simpler. Also, due to security requirements, pages using it must have specific cross-origin isolation headers set.
One canonical example
A parallel counter. Multiple workers process chunks of a file and must increment a shared counter. Without atomics, two workers might read the value '5', both increment it to '6', and both write '6' back, resulting in a lost update. Using Atomics.add(sharedArray, index, 1) ensures each increment is an indivisible operation, guaranteeing the final count is correct.
Interview question
A developer uses SharedArrayBuffer for high-performance parallel processing but omits Atomics operations. What is the most likely outcome?
- a.The SharedArrayBuffer will fail to initialize, preventing any data sharing.
- b.The application will experience race conditions, leading to corrupted or unpredictable data.Correct
- c.Data will be automatically copied between workers, negating performance benefits.
- d.The browser will automatically fall back to standard message passing for communication.
Why? this is the answer
The card explicitly states that 'without Atomics to coordinate, you'll get race conditions and corrupted data.' Atomics are crucial for ensuring atomic operations on shared memory, preventing concurrent access issues. SharedArrayBuffer itself does not fail to initialize or revert to copying data.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #javascript
- #web workers
- #concurrency
- #performance
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on javascript — each one lists the topics its interview covers.
See open roles