Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754974AbZJ0O5s (ORCPT ); Tue, 27 Oct 2009 10:57:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754617AbZJ0O5s (ORCPT ); Tue, 27 Oct 2009 10:57:48 -0400 Received: from hp3.statik.tu-cottbus.de ([141.43.120.68]:49839 "EHLO hp3.statik.tu-cottbus.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753810AbZJ0O5r (ORCPT ); Tue, 27 Oct 2009 10:57:47 -0400 Message-ID: <4AE70A6D.8060700@s5r6.in-berlin.de> Date: Tue, 27 Oct 2009 15:57:49 +0100 From: Stefan Richter User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.23) Gecko/20090825 SeaMonkey/1.1.18 MIME-Version: 1.0 To: "Leonidas ." CC: Michael Schnell , Noah Watkins , linux-kernel Subject: Re: Difference between atomic operations and memory barriers References: <7ADB5FD7-9C97-4987-BC20-997258B25FD2@noahdesu.com> <4AE5F1D2.9030908@s5r6.in-berlin.de> <4AE6C998.9040405@lumino.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1979 Lines: 45 Leonidas . wrote: > On Tue, Oct 27, 2009 at 3:21 AM, Michael Schnell wrote: >> Leonidas . wrote: >>> >>> any_t *ptr = something; >>> >>> is always atomic even on SMPs without using locks, barriers then my >>> doubt is cleared. Thanks. >> >> I assume that this only holds if the pointer (not the thing it points >> to) is denoted as volatile. - Atomic access (either old or new value is visible to CPUs or devices, but never any intermediary, half-baked value), - memory barrier (enforced order of accesses), - volatile qualifier (disabled compiler optimization of accesses) are three different concepts. We rely on atomic pointer load and store all over the kernel, yet never qualify them as "volatile". (A look into the C language spec might bring clarity here. I don't have the spec at hand alas.) > I dont think so, volatile would only ensure no caching, so some cpus > might see the cached pointer (this is where you would want to use > barriers), but pointer assignment would still be atomic. What "volatile" ensures or not ensures is not that well defined in the C language specification as far as I recall prior discussion. Its precise effects are compiler dependent. You are right in so far as volatile (given or missing) does not change whether an access is guaranteed atomic or not. Since it affects compiler optimizations, I think it could possibly affect atomicity of accesses which were never guaranteed to be atomic. But this should not be interesting to 99.99% of all kernel coders because they better use guaranteed atomic accesses when they really need them. (E.g. or pointer load/ store.) -- Stefan Richter -=====-==--= =-=- ==-== http://arcgraph.de/sr/ -- 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/