Date: Tue, 30 Sep 2008 15:38:48 -0500 From: Matt Sealey <matt@genesi-usa.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: <48E28E58.1020901@genesi-usa.com> In-Reply-To: <48DBC59C.3040101@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> <111399E3-2BC7-4724-8AFB-A40F2A47E66D@mac.com> <48DBC59C.3040101@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Isn't there some kind of semaphore primitive in FreeBSD that can be used? I don't understand why you would need to go for all this effort when every atomic-access-requiring variable can simply just be paired with a lock flag (atomic_a and atomic_a_sem). You ask for the semaphore, if you get it, you can write into the value and read from the value, if you do not, you wait until you can get the semaphore.. After all you are basically just implementing a cache-line-sized integrated variable and a new semaphore system here, is NIH really that big a problem? -- Matt Sealey <matt@genesi-usa.com> Genesi, Manager, Developer Relations Rafal Jaworowski wrote: > Marcel Moolenaar wrote: >>> 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. > > Yeah, it seems there are problems with W2 in read-modify-write scenarios... My > environment is simpler (don't need full R-M-W facility). Let me think a bit > about that other algo. > > FWIW, on multicore e500 systems it is possible to do this safely: there is > system wide atomic op monitoring bit HID1[ATS], which lets a given CPU know if > a lwarx/stwcx sequence is in progress on the system, so we can remotely manage > reservations and eliminate wasting some of bus bandwidth. But this is of > course not uniform accross PowerPC implementations. > > Rafal > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48E28E58.1020901>