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

[Matt Sealey]

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 at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe at freebsd.org"