RFR (XS): 8188877: Improper synchronization in offer_termination

[Thomas Schatzl]

Hi all,

On Wed, 2017-11-22 at 09:13 +0000, 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.
> 
> > Either kind of read will eventually notice that its local cached
> > value has been invalidated and will fetch the updated value.
> 
> Eventually, yes.
> 

  so, summing up this discussion, the change is good to go? I think we
can always add any implementation dependent optimizations later.

If everybody agrees, I will push it.

Thanks,
  Thomas