This is the mail archive of the mailing list for the libc-ports project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Update ARM atomic operations question

On Fri, Dec 09, 2005 at 11:13:40AM +0100, Dominique Fober wrote:
> This is a question regarding the patch posted on Wed, 5 Oct 2005 and  
> entitled "Update ARM atomic operations". I'm puzzling about the 2  
> versions of the compare_and_swap primitive included in the patch:
> - with the first version (inline function), 'result' indicates  
> success (1) or failure (0), with the macro version, 'result' seems to  
> always hold the memory value whatever the result of the operation: is  
> it right? and if yes, why? (I've commented the assembly code below  
> with pseudo code and comments to give my understanding of the code)
> - I guess there is a strong rationale behind the two step approach:  
> a) getting the actual value, comparing with the expected value b)  
> trying to swap, but why not directly doing the swap? is it to avoid  
> the race condition in 6) as much as possible?
> - and finally, why moving from an inline typed function  
> implementation to a raw untyped macro?

The answers to all of your questions are the same: the compare_and_swap
obsolete interface has a different calling convention than the new
__arch_compare_and_exchange* interface - that's why it also moved from
atomicity.h to bits/atomic.h.

Returning the old value is more flexible and more generally useful.

Both sequences are load/test followed by swp/cmp/swpne.  They're
basically the same.

Daniel Jacobowitz
CodeSourcery, LLC

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]