Memori Bersama & Operasi Atomik

When building high-performance applications, especially with WebAssembly, you often need to perform tasks concurrently. This means running parts of your code in parallel, perhaps across different threads.

For these concurrent tasks to work together efficiently, they often need to access and modify the same data. This is where shared memory comes in.

You might already know about ArrayBuffer for handling raw binary data in JavaScript. However, a standard ArrayBuffer cannot be directly shared between different execution contexts (like the main thread and a Web Worker, or between JavaScript and a WebAssembly thread).

Each context would get its own copy of the data, which is inefficient and complicated to synchronize for frequent updates.

The solution for true concurrent data access is SharedArrayBuffer. It's a special type of ArrayBuffer that allows the same memory block to be accessed by multiple threads simultaneously.

This means your JavaScript main thread, Web Workers, and WebAssembly modules can all read from and write to the *exact same* underlying data, enabling efficient communication and complex parallel computations.

Due to security vulnerabilities (like Spectre), using SharedArrayBuffer requires specific HTTP response headers to be set by the server:

• Cross-Origin-Opener-Policy: same-origin
• Cross-Origin-Embedder-Policy: require-corp

These headers ensure that the document is in an isolated, cross-origin isolated browsing context, which is necessary for SharedArrayBuffer to function securely.

Creating a SharedArrayBuffer is similar to creating a regular ArrayBuffer. You specify the size in bytes. Then, you can create a typed array view (like Int32Array) to easily interact with the memory.

When a SharedArrayBuffer is passed to a WebAssembly module (e.g., via WebAssembly.Memory), WASM can map this memory into its own linear memory space. This allows WASM code to directly read and write to the shared data.

This direct access is key for performance, as it avoids costly data copying between the host environment (JavaScript) and the WASM module.

While sharing memory is powerful, it introduces a challenge: race conditions. If multiple threads try to read and write to the same memory location at the same time, the final result can be unpredictable or incorrect.

Imagine two threads trying to increment a counter simultaneously. Without proper synchronization, one update might overwrite another, leading to a wrong count.

To prevent race conditions, JavaScript provides the Atomics object. Atomics offer a set of operations that are guaranteed to be atomic, meaning they are indivisible.

An atomic operation either completes entirely or doesn't happen at all, ensuring that no other thread can interrupt it. This guarantees data integrity in shared memory.

The most basic atomic operations are `Atomics.load()` and `Atomics.store()`. These methods ensure that reading and writing values to a shared memory location happens as a single, uninterruptible step.

Beyond simple reads/writes, Atomics provide arithmetic operations like Atomics.add(), Atomics.sub(), Atomics.and(), etc. These perform an operation and update the value atomically.

Atomics.add(typedArray, index, value) adds value to the element at index and returns the old value at that index, all in one safe step.

We've explored how SharedArrayBuffer enables efficient concurrent data access between JavaScript and WebAssembly by allowing multiple threads to access the same memory block.

To prevent data corruption from race conditions, we learned about Atomics, which provide safe, indivisible operations for reading, writing, and modifying data in shared memory.

These tools are crucial for building high-performance, multithreaded WebAssembly applications.