lkml.org 
[lkml]   [2006]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch 00/21] mutex subsystem, -V14
Date
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/

\
 
 \ /
  Last update: 2006-01-06 04:54    [W:0.095 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site