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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
