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

Paul E. McKenney
2008-03-03T17:35:52Z

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@suse.cz>
> >
> > 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@rowland.harvard.edu>
>
> ---
>
> 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.
>
>