On Mon, 3 Mar 2008, Pavel Machek wrote: > Ok... can we get Alan Stern's patch into Documentation/atomic_ops.txt > , then? I was not aware of this, and there seems to be lot of > confusion around... > > Plus... I really don't think we can "just access" this as normal > pointers... due to the compiler issues Alan Cox mentioned, and due to > the ACCESS_ONCE() issue. Here's an updated version of the patch, including the issue Alan Cox brought up. Alan Stern ----------------------------------------------------------------- Atomicity of reads of write for pointers and integral types (other than long long) should be documented, along with the limitations imposed by the compiler. Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> --- Index: usb-2.6/Documentation/atomic_ops.txt =================================================================== --- usb-2.6.orig/Documentation/atomic_ops.txt +++ usb-2.6/Documentation/atomic_ops.txt @@ -21,6 +21,24 @@ local_t is very similar to atomic_t. If updated by one CPU, local_t is probably more appropriate. Please see Documentation/local_ops.txt for the semantics of local_t. +For all properly-aligned pointer and integral types other than long +long, the kernel requires simple reads and writes to be atomic with +respect to each other. That is, if one CPU reads a pointer value at +the same time as another CPU overwrites the pointer, it is guaranteed +that the reader will obtain either the old or the new value of the +pointer, never some mish-mash combination of the two. Likewise, if +one CPU writes a long value at the same time as another CPU does, it +is guaranteed that one or the other of the values will end up stored +in memory, not some mish-mash combination of bits. + +Thus, if all you need is atomicity of reading and writing then you can +use plain old ints, longs, or pointers; you don't need to use +atomic_t. But note: This guarantee emphatically does not apply to +long long values or unaligned values! Note also that gcc does not +guarantee to compile all C assignment expressions into simple writes. +For example, a statement like "x = a + b" might cause gcc to emit code +equivalent to "x = a; x += b", which is decidedly non-atomic. + The first operations to implement for atomic_t's are the initializers and plain reads. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
