From owner-freebsd-smp@FreeBSD.ORG Wed Sep 17 11:22:42 2003 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16C9116A4B3; Wed, 17 Sep 2003 11:22:42 -0700 (PDT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B08E43FBD; Wed, 17 Sep 2003 11:22:40 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: from localhost (localhost [127.0.0.1]) by localhost.cs.rice.edu (Postfix) with ESMTP id EA2284AA38; Wed, 17 Sep 2003 13:22:39 -0500 (CDT) Received: from cs.rice.edu ([127.0.0.1]) by localhost (cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24502-05; Wed, 17 Sep 2003 13:22:37 -0500 (CDT) Received: by cs.rice.edu (Postfix, from userid 19572) id B0AC34A9D7; Wed, 17 Sep 2003 13:22:37 -0500 (CDT) Date: Wed, 17 Sep 2003 13:22:37 -0500 From: Alan Cox To: Frank Mayhar Message-ID: <20030917182237.GM12711@cs.rice.edu> References: <200309171750.h8HHowEf092627@realtime.exit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309171750.h8HHowEf092627@realtime.exit.com> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavis-20030314-p2 at cs.rice.edu cc: smp@freebsd.org Subject: Re: atomicity of unlocked reads X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2003 18:22:42 -0000 On Wed, Sep 17, 2003 at 10:50:58AM -0700, Frank Mayhar wrote: > John Baldwin wrote: > > I think you can assume that the read will be atomic. I don't think FreeBSD > > would work very well on a machine where aligned pointer reads/writes weren't > > atomic. > > I dunno, I tend to think that making such assumptions may well come back to > bite me in the ass when I least expect it. In such situation, I invariably > use some kind of "atomic_xxx_load/store" primitive that does the job safely > and in a machine-dependent way while hiding the details from the MI code. > Indeed. Atomicity of the read is not the only issue. Unless I misunderstood, Bruce is proposing to perform an unsynchronized read of a location that is updated by a different processor. This unsynchronized read is to obtain a pointer. In weaker memory consistency models (than that of the x86), there is no guarantee that the data that the pointer refers to will be consistent. In other words, updates to the data that the pointer refers to may not have completed, even though the update to the memory location containing the pointer has completed. This is what an "acquire load" is for. Roughly speaking, it should guarantee that any updates prior to a corresponding "release store" (by a different processor) will be seen. If we don't use "acquire loads" and "release stores" under such circumstances, the poor guy who ports FreeBSD to a processor that, for example, reorders loads, will be an unhappy camper. Alan