Shared memory sync/update question

T.J. Crowder tj.crowder at farsightsoftware.com
Thu Oct 11 11:18:54 UTC 2018


Hi,

On Thu, Oct 11, 2018 at 11:00 AM Lars Hansen
<lhansen at mozilla.com> wrote:

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

Fantastic, that's exactly what I was hoping.

Thank you again!

-- T.J. Crowder


More information about the es-discuss mailing list