This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Synchronizing auxiliary mutex data
On Tue, 2017-06-20 at 15:55 +0200, Andreas Schwab wrote:
> On Jun 20 2017, Torvald Riegel <triegel@redhat.com> wrote:
>
> > On Tue, 2017-06-20 at 15:40 +0200, Andreas Schwab wrote:
> >> On Jun 20 2017, Torvald Riegel <triegel@redhat.com> wrote:
> >>
> >> > I described exactly that above. It is guaranteed for the code above by
> >> > the memory model. Implementations of the memory model (so in our case,
> >> > the compiler and the HW) have to ensure that. For example, in the x86
> >> > memory model, acquire and release MO are implicit, so because the
> >> > compiler is not allowed to reorder in this case, the HW ensures that
> >> > lock()'s write to owner happens after unlock's write to owner.
> >>
> >> What about the read in the locking thread?
> >
> > I have answered that in my previous emails.
>
> What does prevent the cpu from loading it from its cache?
The correct implementation of the memory model does that.
I'm happy to answer questions, but I don't have time for a continuous
exchange of one-liners. Please try to ask precise questions with the
necessary background included, after you've tried to understand what I
have written.
If you want to understand how this really works, I suggest you become
more familiar with the C11 memory model (e.g., you could watch the
tutorial I gave at the Cauldron 2 years ago for a start). For this
first step, just assume that the C11 memory model is implemented
correctly.
If you want to dig deeper, pick an architecture that you're interested
in and look at how the C11 model, and in particular the atomics, are
implemented on that architecture (e.g., look at the mappings published
by Peter Sewell's group). Then understand what the HW memory model
guarantees -- and there you go (Peter Sewell's group also has formal
models of HW memory models, so the respective papers would be a good
resource as well).