Re: [patch 00/21] mutex subsystem, -V14

[Keith Owens]

Ingo Molnar (on Thu, 5 Jan 2006 23:43:57 +0100) wrote:
>there's one exception i think: atomic-xchg.h was pretty optimal on ARM, 
>and i'd expect it to be pretty optimal on the other atomic-swap 
>platforms too. So maybe we should specify atomic_xchg() to _not_ imply a 
>full barrier - it's a new API anyway. We cannot embedd the barrier 
>within atomic_xchg(), because the barrier is needed at different ends 
>for lock and for unlock, and adding two barriers would be unnecessary.

IA64 defines two qualifiers for cmpxchg, specifically for
distinguishing between acquiring and releasing the lock.

  cmpxchg<sz>.<sem>

<sz> is the data size, 1, 2, 4 or 8.  <sem> is one of 'acq' or 'rel'.

  sem       Ordering    Semaphore Operation
Completer   Semantics
  acq        Acquire    The memory read/write is made visible prior to
                        all subsequent data memory accesses.
  rel        Release    The memory read/write is made visible after all
                        previous data memory accesses.

cmpxchg4.acq prevents following data accesses from migrating before
taking the lock (critical R/W cannot precede critical-START).
cmpxchg4.rel prevents preceding data accesses from migrating after
releasing the lock (critical R/W cannot follow critical-END).  I
suggest adding acq and rel hints to atomic_xchg, and let architectures
that implement suitable operations use those hints.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/