Date: Wed, 24 Sep 2008 12:30:25 -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: <C725D17E-E199-4E70-BE56-07BD21783A7A@mac.com> In-Reply-To: <48DA84D5.4010109@semihalf.com> References: <B4645B39-9D9D-49C5-8F69-55704CD2F6AA@delfi-konsult.com> <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48DA84D5.4010109@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 24, 2008, at 11:20 AM, Rafal Jaworowski wrote: > a.) make sure the whole granule is dedicated for a single object we > want > atomic access to, i.e. in case of a 64-bit object we would use only > 2 words > out of 8 in the given granule and the remaining 6 would be wasted Is this required for correctness? I can see that it is desirable for performance, but I don't think it's needed for correctness. Can you elaborate? > b.) assume our 64-bit object uses word (W1) and word 2 (W2) within > the given > granule Right. This means that 64-bit integrals (i.e. [u]int64_t) should at least be 64-bit aligned. Otherwise you can cross the granule boundary. > 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? -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C725D17E-E199-4E70-BE56-07BD21783A7A>