Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751232AbWCaDUt (ORCPT ); Thu, 30 Mar 2006 22:20:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751225AbWCaDUt (ORCPT ); Thu, 30 Mar 2006 22:20:49 -0500 Received: from omx1-ext.sgi.com ([192.48.179.11]:65234 "EHLO omx1.americas.sgi.com") by vger.kernel.org with ESMTP id S1751206AbWCaDUs (ORCPT ); Thu, 30 Mar 2006 22:20:48 -0500 Date: Thu, 30 Mar 2006 19:20:41 -0800 (PST) From: Christoph Lameter To: "Chen, Kenneth W" cc: Nick Piggin , Zoltan Menyhart , "Boehm, Hans" , "Grundler, Grant G" , akpm@osdl.org, linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org Subject: RE: Synchronizing Bit operations V2 In-Reply-To: <200603310314.k2V3E6g28521@unix-os.sc.intel.com> Message-ID: References: <200603310314.k2V3E6g28521@unix-os.sc.intel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1716 Lines: 49 On Thu, 30 Mar 2006, Chen, Kenneth W wrote: > > What of it? Release semantics are not a full fence or memory barrier. > > The API did not require a full fence. It is defined as a one way fence. Well that explains our misunderstanding. The issue with all these hacky macros is that they all have their own semantics and do not work in a consistent way. More reason to make that explicit. Where may I find that definition? Documentation/atomic_ops.txt implies a complete barrier and gives an example of the use of these macros in order to obtain release semantics. AFAIK that does not mean that this is the intended complete behavior of a "memory barrier": If a caller requires memory barrier semantics around an atomic_t operation which does not return a value, a set of interfaces are defined which accomplish this: void smp_mb__before_atomic_dec(void); void smp_mb__after_atomic_dec(void); void smp_mb__before_atomic_inc(void); void smp_mb__after_atomic_dec(void); For example, smp_mb__before_atomic_dec() can be used like so: obj->dead = 1; smp_mb__before_atomic_dec(); atomic_dec(&obj->ref_count); It makes sure that all memory operations preceeding the atomic_dec() call are strongly ordered with respect to the atomic counter operation. In the above example, it guarentees that the assignment of "1" to obj->dead will be globally visible to other cpus before the atomic counter decrement. - 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/