On Mon, Oct 1, 2018 at 4:42 AM Lars Hansen <[email protected]> wrote: > > In a browser, postMessage send and receive was always intended to > create a synchronization edge in the same way a write-read pair is. > http://tc39.github.io/ecmascript_sharedmem/shmem.html#WebBrowserEmbedding > > Not sure where this prose ended up when the spec was transfered to > the es262 document.
Thanks! Looks like it's at least partially here: https://tc39.github.io/ecma262/#sec-host-synchronizes-with So, a question (well, two questions) just for those of us not deeply versed in the terminology of the Memory Model section. Given: 1. Thread A sends a 1k shared block to Thread B via `postMessage` 2. Thread B writes to various locations in that block directly (not via `Atomics.store`) 3. Thread B does a `postMessage` to Thread A (without referencing the block in the `postMessage`) 4. Thread A receives the message and reads data from the block (not via `Atomics.load`) ...am I correct that in Step 4 it's guaranteed that thread A **will** reliably see the writes to that block by Thread B from Step 2, because the `postMessage` was a "synchronization edge" ensuring (amongst other things) that CPU L1d caches are up-to-date, etc.? Similarly, if (!) I'm reading it correctly, in your Mandlebrot example, you have an `Atomics.wait` on a single location in a shared block, and when the thread wakes up it seems to assume other data in the block (not in the `wait` range) can reliably be read directly. That's also a "synchronization edge"? Thank you again, I appreciate your taking the time. -- T.J. Crowder
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
