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
<[email protected]> 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
[email protected] https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
