Re: xchg() vs test_and_set_bit()

Matthew Wilcox (Matthew.Wilcox@genedata.com)
Sat, 13 Nov 1999 01:25:01 +0100

On Fri, Nov 12, 1999 at 12:16:15PM +0100, Jes Sorensen wrote:
> However, one could achieve the same effect by using xchg(), and looking
> at the code sequences on the x86 and Alpha it actually looks shorter. Of
> course I asume the atomicity of the instruction is the big issue, but
> why not save a word in an instruction cache line if one can? ;-)
> Besides, I can imagine that bitops are likely to be much more complex on
> some architectures, there must be some that don't have bitops operating
> directly on memory.

here's the current implementation on parisc where we have _only_
load-and-zero, which must surely be the most primitive atomic op.

xchg:

spin_lock_irqsave(lock, flags);
temp = *ptr;
*ptr = x;
spin_unlock_irqrestore(lock, flags);

(unless you're xchg'ing with a constant zero, in which case we use the
primitive we have. Most of the xchg's in the kernel use this form.)

um. no-one's made the test_and_set_bit code atomic yet. But it's going
to suck worse than this. If the contention on the xchglock becomes too
great, we can hash on the value of `ptr' and have an array of locks.

ARM has load-and-store, which must be the next most primitive atomic op.
that makes xchg a no-brainer, but test-and-set-bit is quite hard.

I'm having trouble thinking of a design where xchg would be worse
than test-and-phi.

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/