Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758166AbYCCPmp (ORCPT ); Mon, 3 Mar 2008 10:42:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754869AbYCCPmh (ORCPT ); Mon, 3 Mar 2008 10:42:37 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:33088 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1754644AbYCCPmh (ORCPT ); Mon, 3 Mar 2008 10:42:37 -0500 Date: Mon, 3 Mar 2008 10:42:35 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Pavel Machek cc: "Paul E. McKenney" , Linus Torvalds , Andrew Morton , Zdenek Kabelac , , "Rafael J. Wysocki" , Pierre Ossman , Kernel development list , pm list Subject: Re: [patch] Re: using long instead of atomic_t when only set/read is required In-Reply-To: <20080303120842.GA28369@elf.ucw.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3144 Lines: 81 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? > Ok, so linux actually atomicity of long? > > If so, this should probably be applied... > > Signed-off-by: Pavel Machek > > 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 --- 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/