This is the mail archive of the
mailing list for the libc-ports project.
Re: Update ARM atomic operations question
- From: Daniel Jacobowitz <drow at false dot org>
- To: Dominique Fober <fober at grame dot fr>
- Cc: libc-ports at sources dot redhat dot com
- Date: Fri, 9 Dec 2005 09:46:06 -0500
- Subject: Re: Update ARM atomic operations question
- References: <A9404784-7F49-426C-AF56-F669332D227E@grame.fr>
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.