Parallel scanning of large data sets, like object graphs. You don't want to copy the entire graph to each thread, nor do fine grained passing around of a node per traversal.

However, if what this exposes is just an array of bytes, that's less useful as you have to cast your own object model on top of it. Large image data might be still useful as just bytes, with threads running convolutions or NNs on it.

It isn't the only way to handle concurrency, but they are the only primitives that can be used to port existing code (C/C++/Rust/etc) into the browser sandbox without killing performance, or introducing crazier and unsound primitives (like stack manipulation).

I've used SharedArrayBuffers to port things like latex into the browser ( https://browsix.org ), and without it you can't use wasm or asm.js, you need to interpret C code in JavaScript to save/restore the stack on system calls.

> It isn't the only way to handle concurrency, but they are the only primitives that can be used to port existing code (C/C++/Rust/etc) into the browser sandbox without killing performance

I thought a big reason why we have WASM is so that that emphatically does not need to be a concern of JS.

Shared memory + locks isn't about concurrency, but probably about parallelism. If you just need concurrency, then messaging between web workers should be good enough.

Fundamentally, you have to implement every other approach using locks behind the scenes (with the possible exception of immutable data).

It may not be an idea user primitive, but serves library makers well.

I think the main use case is to support c++ codebases compiled with emscripten without having to rewrite the whole codebase to not assume shared mutable state.