Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751200AbWCaCz7 (ORCPT ); Thu, 30 Mar 2006 21:55:59 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751194AbWCaCz6 (ORCPT ); Thu, 30 Mar 2006 21:55:58 -0500 Received: from omx2-ext.sgi.com ([192.48.171.19]:25305 "EHLO omx2.sgi.com") by vger.kernel.org with ESMTP id S1750807AbWCaCz6 (ORCPT ); Thu, 30 Mar 2006 21:55:58 -0500 Date: Thu, 30 Mar 2006 18:55:47 -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: <200603310250.k2V2ofg28252@unix-os.sc.intel.com> Message-ID: References: <200603310250.k2V2ofg28252@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: 702 Lines: 19 On Thu, 30 Mar 2006, Chen, Kenneth W wrote: > By the way, this is the same thing on x86: look at include/asm-i386/bitops.h: > > #define smp_mb__before_clear_bit() barrier() > #define smp_mb__after_clear_bit() barrier() > > A simple compiler barrier, nothing but > #define barrier() __asm__ __volatile__("": : :"memory") > > See, no memory ordering there, because clear_bit already has a LOCK prefix. And that implies barrier behavior right? - 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/