RFR (XS): 8188877: Improper synchronization in offer_termination

[Thomas Schatzl]

Hi again,

On Mon, 2017-11-27 at 10:30 +0100, Thomas Schatzl wrote:
> 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.

  and btw, looks good :)

Thomas