Re: thoughts on libatomic

[Torvald Riegel <triegel at redhat dot com>]

On Mon, 2012-04-23 at 12:29 -0700, Richard Henderson wrote:
> On 04/16/12 11:15, Torvald Riegel wrote:
> > - for acq/rel memorders, we don't need seq_cst fences whenever the
> >   atomicity is implemented with a lock
> >   (hostconfig.c:pre_barrier/post_barrier)
> 
> Err.. where?  This also seems to conflict with...

I thought on the fallback paths that use locks.  Locks typically use
acq/rel semantics, so for the particular location, we don't need
pre/post barrier code to be run.

Or maybe it didn't happen, and the one below is correct.  Sorry for the
potential mix-up.  I can look at this again after PTO.

> 
> > - protect_start|end:
> >   - BUG: those are called without additional post|pre_barrier calls in
> >     cas_n.c, exch_n.c, fop_n.c, load_n.c, store_n.c
> >     The lock membar guarantees are too weak if memorder for the atomic
> >     access is seq_cst, and if you use more than one lock.
> >     (assumes that lock implementation uses typical acq/rel barriers).
> 
> ... this.  I don't see what multiple locks has to do with seq vs acqrel.

If we don't run seq_cst membars when falling back to locks, then seq_cst
operations on two locations ordered by acq/rel locks will not be forced
to be in one total order (which seq_cst requires).  They will be ordered
per lock, but not globally.

> > - config/posix/lock.c:
> >   - I'm not sure that WATCH_SIZE should almost certainly be the same as
> >     the cacheline size.  Why?  Which assumptions about the program?
> 
> See above.  Plus I assumed that if we have to take a lock, that's got to
> dominate over any cache ping-pong that would be played.

Perhaps the cache ping-pong dominates (and this assumes that the lock is
contended).  But perhaps the cache ping-pong wouldn't be worse than the
contention potentially introduced from a too-coarse-grained lock?

> >   - Do locks need to care about priority inversion?
> 
> At the moment I'm leaving this with the pthread implementation.

pthreads offers PI-safe locks too.  But I also don't know whether we
need this.