On Mon, Mar 03, 2008 at 10:42:35AM -0500, Alan Stern wrote: > On Mon, 3 Mar 2008, Pavel Machek wrote: > > > Hi! > > > > > > Alan thinks that `subj` is correct... > > > > > > More precisely, reads and writes of pointers are always atomic. That > > > is, if a write and a read occur concurrently, it is guaranteed that the > > > read will obtain either the old or the new value of the pointer, never > > > a mish-mash of the two. If this were not so then RCU wouldn't work. > > Right, Paul? Yep, as long as they aligned naturally, e.g., 32-bit pointers to a four-byte boundary, 64-bit pointers to an eight-byte boundary. Note that this is a backdoor agreement between the Linux kernel and gcc. The C/C++ standard does -not- require atomic reads or writes for anything other than a volatile sig_atomic_t. In fact, there are a lot of things that C/C++ doesn't guarantee, which is why Linux makes use of so many of gcc's non-standard extensions. ;-) > > Ok, so linux actually atomicity of long? Yep, same alignment rules as pointers. Ah, and the alignment is covered below. Very good! > > If so, this should probably be applied... > > > > Signed-off-by: Pavel Machek <pavel@xxxxxxx> > > > > diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt > > index 4ef2450..0a7d180 100644 > > --- a/Documentation/atomic_ops.txt > > +++ b/Documentation/atomic_ops.txt > > @@ -21,6 +21,9 @@ 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. > > > > +long (and int and void *) can be used instead of atomic_t, if all you > > +need is atomic setting and atomic reading. > > + > > The first operations to implement for atomic_t's are the initializers and > > plain reads. > > Yes indeed. This fact doesn't seem to be documented anywhere, but it > is clearly a requirement of the kernel. I would make the text a little > more explicit, see below. > > Alan Stern > > ------------------------------------------------------- > > > Atomicity of reads of write for pointers and integral types (other than > long long) should be documented. > > 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,21 @@ 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!) > + > 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
