This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Synchronizing auxiliary mutex data


On Tue, 2017-06-20 at 14:42 +0200, Andreas Schwab wrote:
> On Jun 20 2017, Torvald Riegel <triegel@redhat.com> wrote:
> 
> > You were talking about ordering of the writes. to __owner.  This happens
> > through the happens-before established through the unlock->lock
> > synchronization.  Specifically, in unlock:
> >   store(&owner, 0, mo_relaxed) ->sb store(&lock, 0, mo_release)
> > and in lock:
> >   cas(&lock, expect==0, new==1, mo_acquire)==success
> >     ->sb store(&owner, TID, mo_relaxed)
> > where ->sb is sequenced-before, so essentially program order.  The CAS
> > that succeeds is a load too that reads-from the store in unlock that
> > writes 0.
> 
> I don't understand how writing to lock has any influence on the access
> to owner.  What guarantees that the modification of owner in the
> unlocking thread is seen by the locking thread?

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]