مشاركة الذاكرة باستخدام SharedArrayBuffer وAtomics

When you spin up a Worker in Node.js and call postMessage, the data you send is copied using the structured clone algorithm. For small messages that is fine, but for a large numeric buffer (millions of bytes) copying wastes CPU and memory.

• SharedArrayBuffer lets multiple threads read and write the same block of memory with zero copying.
• Atomics gives you safe, race-free operations on that memory.

This lesson shows how to coordinate threads over shared memory in a CPU-bound backend job.

An ArrayBuffer is owned by one thread. When transferred to a worker, the sender loses access to it. A SharedArrayBuffer (SAB) is different: passing it to a worker shares the same backing store, so both threads see each other's writes.

You never read raw bytes directly. Instead you wrap the buffer in a typed array view such as Int32Array or Float64Array.

To share memory, create the SharedArrayBuffer in the main thread and send it via postMessage. Unlike a normal buffer, a SAB is shared (not transferred), so both sides keep using it.

The worker wraps the same SAB in its own typed array view. No copy happens.

Plain reads and writes on a shared view are not safe when multiple threads touch the same slot. A statement like view[0] += 1 is really three steps: read, add, write. Two threads can interleave and lose updates.

• Thread A reads 5, Thread B reads 5.
• Both compute 6 and write 6.
• Two increments happened, but the value only went up by one.

This is a classic data race. The fix is Atomics.

Atomics.add(view, index, value) performs read-modify-write as a single indivisible operation. No other thread can interleave, so increments are never lost.

Other useful methods: Atomics.sub, Atomics.and, Atomics.or, and Atomics.load / Atomics.store for plain reads and writes that are guaranteed visible across threads.

Imagine summing a huge array of integers, a CPU-bound task that would block the event loop. With shared memory you store the data once and let several workers each process a slice, writing partial results into a shared output slot via Atomics.add.

Because the input lives in a SharedArrayBuffer, you never copy the dataset to each worker. They all read the same bytes.

Atomics.compareExchange(view, index, expected, replacement) writes replacement only if the current value equals expected, and returns the value that was there. This is the building block for lock-free algorithms and simple spinlocks.

Use it to claim a slot exactly once: if the swap succeeds, this thread won the claim.

Sometimes a worker must pause until another thread signals it. Atomics.wait(view, index, expectedValue) blocks the calling thread while the slot still holds expectedValue. It returns 'ok', 'not-equal', or 'timed-out'.

• Atomics.wait only works off the main thread (it would freeze the event loop otherwise).
• Atomics.notify(view, index, count) wakes waiting threads.

This gives you a true thread barrier without busy-looping.

The producer thread updates the shared slot with Atomics.store and then calls Atomics.notify to wake any thread parked in Atomics.wait. The order matters: change the value first, then notify.

In a real backend job this is how a coordinator releases all workers at once to start a phase, or signals that input is ready.

Here is the full pattern in one runnable file: a shared input buffer, a shared result slot, and two workers that each sum half the data and atomically add their partial into the result. The main thread waits for both to finish.

Notice the input is never copied; both workers read the same SharedArrayBuffer.

Shared memory is powerful but easy to misuse. Keep these rules in mind:

• SharedArrayBuffer only stores numbers. To share strings or objects you must encode them (for example with TextEncoder into a Uint8Array).
• Always use Atomics for any slot more than one thread might write; mixing plain writes and atomic writes reintroduces races.
• Reserve a fixed slot for synchronization flags and document its index.
• Use shared memory only when copying is a real bottleneck; for most messages plain postMessage is simpler and safe.

You learned how to coordinate Node.js worker threads over shared memory:

• SharedArrayBuffer shares one backing store across threads with no copying; wrap it in a typed array like Int32Array.
• Plain += on a shared slot causes data races; use Atomics for any concurrently written slot.
• Atomics.add, Atomics.load, Atomics.store, and Atomics.compareExchange give race-free reads, writes, and lock-free claims.
• Atomics.wait (off the main thread) plus Atomics.notify let threads block and signal without busy-looping.
• Reach for shared memory only when copying large numeric buffers is a real bottleneck.