To share memory using SharedArrayBuffer objects from one agent in the cluster to another (an agent is either the web page’s main program or one of its web workers), postMessage and structured cloning is used.
=== end quote ===
And, of course, they are almost exclusively used with Web Workers because it makes zero sense to use them in the context of a single page. They are basically memory-mapped files, but for the browser, and their presence doesn't make Javascript and its runtime multithreaded.
IIRC Javascript can't even be made multithreaded because there are places in the spec that can't work in a multithreaded environment, but don't quote me on that.
> However, the shared data block referenced by the two SharedArrayBuffer objects is the same data block, and a side effect to the block in one agent will eventually become visible in the other agent.
This gives you shared memory between two threads. Sure the entire address space isn't shared but I find it hard to deny that this is threading.
> This gives you shared memory between two threads.
This is the key point you're missing. It's not "two threads". It's to different isolated tasks/processes.
Shared array buffers are quite literally what memory-mapped files have been used for over 40 years [1]
=== start quote ===
Another common use for memory-mapped files is to share memory between multiple processes. In modern protected mode operating systems, processes are generally not permitted to access memory space that is allocated for use by another process... There are a number of techniques available to safely share memory, and memory-mapped file I/O is one of the most popular. Two or more applications can simultaneously map a single physical file into memory and access this memory.
=== end quote ===
That's all there is: two separate, isolated processes accessing the same memory. This doesn't make Javascript multithreaded in any way, shape, or form. Browsers give you a rather awkward way to run a separate tasks in Javascript and give you message-passing and shared memory as a way to communicate between them.
Had browsers been able to run other languages than Javascript, you would be able to run one worker in Javascript, and another in SadlyNonExistentScript, and literally nothing would change: you would still have the same postMessage and SharedArrayBuffer as APIs provided by the host.
To run workers isolated from each other when Javascript doesn’t support multithreading, worker threads use a special mechanism.
We all know Node runs on top of Chrome’s V8 engine. V8 supports the creation of isolated V8 runtimes. These isolated instances, known as V8 Isolate , have their own Javascript heaps and micro-task queues.
Worker threads are run on these isolated V8 engines, each worker having its own V8 engine and event queue. In other words, when workers are active, a Node application has multiple Node instances running in the same process.
=== start quote ===
To share memory using SharedArrayBuffer objects from one agent in the cluster to another (an agent is either the web page’s main program or one of its web workers), postMessage and structured cloning is used.
=== end quote ===
And, of course, they are almost exclusively used with Web Workers because it makes zero sense to use them in the context of a single page. They are basically memory-mapped files, but for the browser, and their presence doesn't make Javascript and its runtime multithreaded.
There's also a good overview on the history of concurrency and parallelism in JS here: https://exploringjs.com/es2016-es2017/ch_shared-array-buffer...
IIRC Javascript can't even be made multithreaded because there are places in the spec that can't work in a multithreaded environment, but don't quote me on that.