From owner-freebsd-ppc@FreeBSD.ORG Wed Sep 24 21:07:09 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C81D61065687 for ; Wed, 24 Sep 2008 21:07:09 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id ACFCD8FC16 for ; Wed, 24 Sep 2008 21:07:09 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.95] (209-128-86-226.bayarea.net [209.128.86.226]) by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K7P00CBNXBVD580@asmtp019.mac.com> for freebsd-ppc@freebsd.org; Wed, 24 Sep 2008 14:07:09 -0700 (PDT) Message-id: <111399E3-2BC7-4724-8AFB-A40F2A47E66D@mac.com> From: Marcel Moolenaar To: Rafal Jaworowski In-reply-to: <48DA99F8.7070904@semihalf.com> Date: Wed, 24 Sep 2008 14:07:07 -0700 References: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48DA84D5.4010109@semihalf.com> <48DA99F8.7070904@semihalf.com> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-ppc@freebsd.org Subject: Re: 64-bit atomic ops on 32-bit CPU -- was: ZFS .. on PowerPC ? X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2008 21:07:09 -0000 On Sep 24, 2008, at 12:50 PM, Rafal Jaworowski wrote: > The strict requirement is having all words of the compound atomic > object > within the same granule. I agree. >>> Atomic store skeleton (pseudo asm, but you'll get the idea): >>> >>> 1. lwarx W1 >>> >>> 2. stw W2 >>> This regular (non-stwcx) store issued from local CPU will not >>> clear our >>> reservation on this granule (only external CPUs or other entities' >>> stores >>> within this granule can clear it) >>> >>> 3. stwcx W1, goto p.1 if not succeeded >> >> I don't see a read of W2. In particular, we clobber W2 >> unconditionally, so we must guarantee that we always >> read the correct value of W2. Can you elaborate on how >> an increment would be made atomic? > > This was an example of an atomic write when we don't care about the > previous > state (there, the initial lwarx is only needed for obtaining the > reservation). > > Atomic increment would be like this: > 1. lwarx W1 > > 2. lwz W2 > 3. In-register increment/other modification > 4. stw W2 (modified) > Neither 2. nor 3 issued from local CPU will not clear our > reservation on this > granule. > > (optionally increment/modify in-register value of W1) > 5. stwcx W1, goto p.1 if not succeeded Ok. Let's assume we lose the reservation and we're forced to loop and try again. Step 2 then reads W2, which on a retry is the word written in step 4. As such, if we have to loop and retry X times, then the atomic increment would increment by X and not 1. I don't think an unconditional write to W2 will work if we don't preserve the origional value of W2. -- Marcel Moolenaar xcllnt@mac.com