Re: [patch] Re: using long instead of atomic_t when only set/read is required

[Paul E. McKenney]

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.
> 
> 
--
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/