Shared memory sync/update question

Gus Caplan me at gus.host
Sun Sep 23 04:12:32 UTC 2018


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> 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/20180922/4079b833/attachment.html>


More information about the es-discuss mailing list