64-bit atomic ops on 32-bit CPU -- was: ZFS .. on PowerPC ?

Rafal Jaworowski raj at semihalf.com
Thu Sep 25 17:08:48 UTC 2008


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


More information about the freebsd-ppc mailing list