Messages in this thread | | | From | Keith Owens <> | Subject | Re: [patch 00/21] mutex subsystem, -V14 | Date | Fri, 06 Jan 2006 14:49:51 +1100 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |