RFR (XS): 8188877: Improper synchronization in offer_termination

[Andrew Dinn]

On 22/11/17 09:13, Andrew Haley wrote:
> On 21/11/17 21:53, White, Derek wrote:
>> My understanding is that the "acquire" semantics are entirely about
>> memory ordering, within a CPU. In particular it prevents "following
>> loads" from executing before the "load acquire".
>>
>>
>> There is nothing in the "load acquire" that causes it to synchronize
>> with the memory system more or less quickly than a naked load.
> 
> The abstract architecture only specifies things in terms of ordering
> between loads, but it has to be implemented somehow, and this is MESI
> or something similar.  Stores cause invalidate messages to be sent,
> and these are put into the reader's invalidate queue.  When that
> reader executes a load barrier it marks all the entries currently in
> its invalidate queue.  The next load will wait until all marked
> entries have been applied to the reader's cache.

That's what happens when the reader executes a read barrier. The
interesting question is what happens when the reader does not execute a
read barrier.

>> Either kind of read will eventually notice that its local cached
>> value has been invalidated and will fetch the updated value.
> 
> Eventually, yes.
That's a rather ill-defined span of time ;-)

I understand that you tested this and found that it took no longer than
a few hundred microseconds. However, I really have to ask what precisely
the reader was doing during the test?

Specifically, does the time taken to 'eventually' notice a write to the
LDRed location depend upon what other instructions are executed between
successive LDRs?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander