Re: Question from Russells Spinlocks

[Robert Love]

On Thu, 2004-12-09 at 21:15 +0000, kernel-stuff@xxxxxxxxxxx wrote:

This part is incorrect (and horribly wrapped):

>  The comment about  atomic_t - It is due to the fact that some ( IA-32 for e.g.) architectures guarantees atomicity of integer operations for only 24 bits. So you could possibly manipulate only 24 out of the 32 bits atomically - that's the hardware guarantee. The comments reflect this fact. (Pointers are 32bits on IA32 so it applies to pointer as well.)

The reason for the 24-bit limit on atomic_t is because SPARC32's
implementation of atomic operations was limited to 24-bits per atomic
integer, because the architecture provides very minimal atomic support,
we had to embed a byte-sized lock in the word.  This limited SPARC32's
atomic integer to 24 usable bits.  The other architectures can, of
course, hold the full 32-bits but to be compatible code must assume the
24-bit limit.

Although this was fixed recently in 2.6 so it actually no longer
applies.

	Robert Love


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