Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764476AbYCFQN1 (ORCPT ); Thu, 6 Mar 2008 11:13:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S934562AbYCFQMx (ORCPT ); Thu, 6 Mar 2008 11:12:53 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:44735 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934549AbYCFQMw (ORCPT ); Thu, 6 Mar 2008 11:12:52 -0500 Date: Thu, 6 Mar 2008 08:11:59 -0800 (PST) From: Linus Torvalds To: Mark Lord cc: Alan Stern , Alan Cox , Pavel Machek , "Paul E. McKenney" , Andrew Morton , Zdenek Kabelac , davem@davemloft.net, "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: <47D014A6.9090300@rtr.ca> Message-ID: References: <47D014A6.9090300@rtr.ca> User-Agent: Alpine 1.00 (LFD 882 2007-12-20) 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: 1424 Lines: 37 On Thu, 6 Mar 2008, Mark Lord wrote: > > But also consider something like this: > > void store_task(void) > { > *the_task = current; > } > > In this case, there is no guarantee that the assignment > can be done atomically on all CPU types. Some RISC archs > (eg. MIPS R2xxx) require an (interruptible) instruction pair > to store values to a potentially unaligned address. You'd better not be using unaligned accesses for memory-ordering-sensitive things (I think x86 happens get even that right for most cases, but I don't think the architecture specification guarantees it, and I'm pretty sure that you might find problems on cache crossing writes, for example) But quite frankly, if you have an architecture that can't do the above as a single write when it's a pointer, then you have a totally broken architecture. It's not worth supporting. (There are data structures that are harder than native words: bytes and shorts can require load-modify-write cycles, and "u64" and friends can obviously be multiple words, so you shouldn't depend on things for those "complex" cases. But we *definitely* depend on atomicity for regular word accesses). Linus -- 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/