Shared memory sync/update question

T.J. Crowder tj.crowder at farsightsoftware.com
Sun Sep 23 13:10:24 UTC 2018


On Sun, Sep 23, 2018 at 5:12 AM Gus Caplan
<me at gus.host> wrote:
>
> Shared memory doesn't need to "sync", its the same memory. Atomics exists
> to provide primitives to help with timing (mostly race conditions).

Thanks. Perhaps I'm being misled by my experience with the Java memory
model, which is of course different to JavaScript's. But my understanding
is that a CPU (and possibly the JS VM itself) may cache a copy of shared
memory for each thread to improve parallel processing. So while it's the
same memory in theory, there are local thread-specific copies of parts of
it which can (and in Java, do) mean a thread can write a value to a shared
variable and another thread won't see that new value without
synchronization of some kind to force flushing those caches, etc. The
(fantastic) articles by Lin Clark you linked on SO don't talk about that at
all. Are you saying that doesn't happen with JavaScript's memory model?
That seems unlikely to me, I'd want a canonical source on it. But I could
imagine (and this is pure invention) that using an `Atomics` method on a
buffer, in addition to ensuring no reordering etc., also triggers a
cache-flushing event or similar.

-- T.J. Crowder

On Sun, Sep 23, 2018 at 5:12 AM Gus Caplan <me at gus.host> wrote:

> Shared memory doesn't need to "sync", its the same memory. Atomics exists
> to provide primitives to help with timing (mostly race conditions).
>
> For example, if you want to update an index in a SharedArrayBuffer (SAB)
> so that another thread may read it, the safe way is to use Atomics.wait in
> the thread that will read from the SAB, and Atomics.store plus
> Atomics.notify in the thread that writes to the SAB.
>
>
> ---- On Sat, 22 Sep 2018 16:28:41 -0500 *T.J. Crowder
> <tj.crowder at farsightsoftware.com <tj.crowder at farsightsoftware.com>>*
> wrote ----
>
> Can anyone on the list help me with the shared memory details question
> described here:
> [Does `postMessage` or yielding to the event loop or similar sync shared
> memory?][1]
>
> It seems like Lars T. Hansen's Mandlebrot example [here][2] also expects
> memory to have been synchronized/updated as of the receipt of a
> `postMessage` message (when a worker is done, it triggers a `workerDone`
> message making the main thread redisplay), but there's an `Atomics.store`
> involved there.
>
> Just trying to get a clear idea of when (and whether) one can reliably,
> in-specification trust that a thread will see updates from other threads
> without using `Atomics.load` or similar to do every single read. Hansen's
> Mandlebrot example uses a lock on a single element via `compareExchange`.
> My experiment that never sees a stale read doesn't use `Atomics` at all
> (but see the first link above for details).
>
> Thanks in advance,
>
> -- T.J. Crowder
>
> [1]:
> https://stackoverflow.com/questions/52445807/does-postmessage-or-yielding-to-the-event-loop-or-similar-sync-shared-memory
>
> [2]:
> https://hacks.mozilla.org/2016/05/a-taste-of-javascripts-new-parallel-primitives/
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180923/c0a24bf4/attachment.html>


More information about the es-discuss mailing list