On Mar 13, 2007, at 5:41 AM, Joerg Sonnenberger wrote:

> On Mon, Mar 12, 2007 at 11:28:47PM -0700, Jason Thorpe wrote:
>> The API is borrowed from Solaris.  There is one major difference,
>> however.  Solaris defines "cas" as COMPARE-AND-SWAP, returning the
>> previous value of the memory cell.  I have defined it as COMPARE-AND-
>> STORE, returning true if the ops succeeds, or false otherwise.  The
>> reason for this is because some platforms will have extreme  
>> difficulty
>> implementing COMPARE-AND-SWAP, whereas COMPARE-AND-STORE is somewhat
>> easier for these platforms.
>
> This is just an additional branch to get compare-and-swap, right? I
> don't have a problem with the compare-and-store, that's often
> preferable, actually.

Compare-and-swap would atomically return the old value even in the  
case where the swap was not performed, but many platforms don't have  
instructions that can do this.

>
>> 1. 8-bit and 16-bit operations are to be used sparingly because, on
>> some (most?) platforms, they are extremely expensive compared to the
>> corresponding 32-bit (or 64-bit, if available) operation.
>
> getting the current value, bitmasking, cas? possible retry if the
> changed bits for not the one we wanted to change. Right?

That's correct.  And for that reason, I also need to document that  
these operations only work on regular memory, not device memory (which  
may have side-effects that makes the read-modify-write unsafe).

-- thorpej