Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751194AbWIHWZ1 (ORCPT ); Fri, 8 Sep 2006 18:25:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751195AbWIHWZ0 (ORCPT ); Fri, 8 Sep 2006 18:25:26 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:2824 "HELO iolanthe.rowland.org") by vger.kernel.org with SMTP id S1751194AbWIHWZZ (ORCPT ); Fri, 8 Sep 2006 18:25:25 -0400 Date: Fri, 8 Sep 2006 18:25:24 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Oliver Neukum cc: paulmck@us.ibm.com, David Howells , Kernel development list Subject: Re: Uses for memory barriers In-Reply-To: <200609082346.20740.oliver@neukum.org> Message-ID: 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: 938 Lines: 26 On Fri, 8 Sep 2006, Oliver Neukum wrote: > > Again you have misunderstood. The original code was _not_ incorrect. I > > was asking: Given the code as stated, would the assertion ever fail? > > I claim the right to call code that fails its own assertions incorrect. :-) Touche! > > The code _was_ correct for my purposes, namely, to illustrate a technical > > point about the behavior of memory barriers. > > I would say that the code may fail the assertion purely based > on the formal definition of a memory barrier. And do so in a subtle > and inobvious way. But what _is_ the formal definition of a memory barrier? I've never seen one that was complete and correct. Alan Stern - 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/