Date: Wed, 24 Sep 2008 14:07:07 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Rafal Jaworowski <raj@semihalf.com> Cc: freebsd-ppc@freebsd.org Subject: Re: 64-bit atomic ops on 32-bit CPU -- was: ZFS .. on PowerPC ? Message-ID: <111399E3-2BC7-4724-8AFB-A40F2A47E66D@mac.com> In-Reply-To: <48DA99F8.7070904@semihalf.com> References: <B4645B39-9D9D-49C5-8F69-55704CD2F6AA@delfi-konsult.com> <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48DA84D5.4010109@semihalf.com> <C725D17E-E199-4E70-BE56-07BD21783A7A@mac.com> <48DA99F8.7070904@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?111399E3-2BC7-4724-8AFB-A40F2A47E66D>