* Paul Jackson <[EMAIL PROTECTED]> wrote:
> A long time ago, Linus wrote:
> > An atomic op is pretty much as expensive as a spinlock/unlock pair on x86.
> > Not _quite_, but it's pretty close.
>
> Are both read and modify atomic ops relatively expensive on some CPUs,
> or is it just modify atomic ops?
>
> (Ignoring for this question the possibility that a mix of read and
> modify ops could heat up a cache line on multiprocessor systems, and
> focusing for the moment just on the CPU internals ...)
if by 'some CPUs' you mean x86 then it's the LOCK prefixed ops that are
expensive. I.e. all the LOCK-prefixed RMW variants of instructions:
atomic.h: LOCK "addl %1,%0"
atomic.h: LOCK "subl %1,%0"
atomic.h: LOCK "subl %2,%0; sete %1"
atomic.h: LOCK "incl %0"
atomic.h: LOCK "decl %0"
atomic.h: LOCK "decl %0; sete %1"
atomic.h: LOCK "incl %0; sete %1"
atomic.h: LOCK "addl %2,%0; sets %1"
atomic.h: LOCK "xaddl %0, %1;"
atomic.h:__asm__ __volatile__(LOCK "andl %0,%1" \
atomic.h:__asm__ __volatile__(LOCK "orl %0,%1" \
pure reads/writes are architecturally guaranteed to be atomic (so
atomic.h uses them, not some fancy instruction) and they are (/better
be) fast.
interestingly, the x86 spinlock implementation uses a LOCK-ed
instruction only on acquire - it uses a simple atomic write (and
implicit barrier assumption) on the way out:
#define spin_unlock_string \
"movb $1,%0" \
:"=m" (lock->slock) : : "memory"
no LOCK prefix. Due to this spinlocks can sometimes be _cheaper_ than
doing the same via atomic inc/dec.
Ingo
-
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/
