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.
