Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> 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" \
>
Ingo wrote:
> if by 'some CPUs' you mean x86 then it's the LOCK prefixed ops ...
Yup - that's the one. Thanks.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373,
1.925.600.0
* 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 ato
True - thanks - including the part about the cost of locking bugs.
My question was poorly phrased - the code speaks the answer to the
real question I had:
$ grep define.atomic_ include/asm-ia64/atomic.h | head -2
#define atomic_read(v) ((v)->counter)
#define atomic_set(v,i)
On Thu, 27 Jan 2005, Paul Jackson 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 at
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 th
6 matches
Mail list logo
