Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751403AbWCaQWF (ORCPT ); Fri, 31 Mar 2006 11:22:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751401AbWCaQWF (ORCPT ); Fri, 31 Mar 2006 11:22:05 -0500 Received: from palrel13.hp.com ([156.153.255.238]:16769 "EHLO palrel13.hp.com") by vger.kernel.org with ESMTP id S1751400AbWCaQWE (ORCPT ); Fri, 31 Mar 2006 11:22:04 -0500 Date: Fri, 31 Mar 2006 08:22:22 -0800 (PST) From: Hans Boehm X-X-Sender: hboehm@tomil.hpl.hp.com To: Andi Kleen Cc: Christoph Lameter , Zoltan Menyhart , "Boehm, Hans" , "Grundler, Grant G" , "Chen, Kenneth W" , akpm@osdl.org, linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org Subject: Re: Synchronizing Bit operations V2 In-Reply-To: Message-ID: References: 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: 1481 Lines: 41 I would argue that there are two semi-viable approaches to this: 1) Guarantee that all atomic operations always include a full memory fence/barrier. That way the programmer can largely ignore associated memory ordering issues. 2) Make the ordering semantics as explicit and clean as possible, which is being proposed here. It seems to me that anything in the middle doesn't work well. If programmers have to think about ordering at all, you want to make it as difficult as possible to overlook. My impression is that approach (1) tends not to stick, since it involves a substantial performance hit on architectures on which the fence is not implicitly included in atomic operations. Those include Itanium and PowerPC. Hans On Fri, 31 Mar 2006, Andi Kleen wrote: > Christoph Lameter writes: > > MODE_BARRIER > > An atomic operation that is guaranteed to occur between > > previous and later memory operations. > > > I think it's a bad idea to create such an complicated interface. > The chances that an average kernel coder will get these right are > quite small. And it will be 100% untested outside IA64 I guess > and thus likely be always slightly buggy as kernel code continues > to change. > > -Andi > - 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/