Shared memory sync/update question

Lars Hansen lhansen at
Thu Oct 11 10:00:48 UTC 2018

On Tue, Oct 2, 2018 at 2:20 PM, T.J. Crowder <
tj.crowder at> wrote:

> On Mon, Oct 1, 2018 at 4:42 AM Lars Hansen
> <lhansen at> 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.
> >
> 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:
> 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
> ``)
> 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`)
> 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.?

Yes, that was the intent of that language.  The writes to the memory should
happen-before the postMessage and the receive-message should happen-before
the reads.

> 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"?

Yes, same argument.  The writes happen-before the wake, and the wakeup of
the wait happens-before the reads.

All of this is by intent so as to allow data to be written and read with
cheap unsynchronized writes and reads, and then for the (comparatively
expensive) synchronization to ensure proper observability.


> Thank you again, I appreciate your taking the time.
> -- T.J. Crowder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list