Russell King wrote:
On Sat, Dec 17, 2005 at 12:01:27AM +1100, Nick Piggin wrote:
You were proposing a worse default, which is the reason I suggested it.
I'd like to qualify that. "for architectures with native cmpxchg".
For general consumption (not specifically related to mutex stuff)...
For architectures with llsc, sequences stuch as:
load
modify
cmpxchg
are inefficient because they have to be implemented as:
load
modify
load
compare
store conditional
Now, if we consider using llsc as the basis of atomic operations:
load
modify
store conditional
and for cmpxchg-based architectures:
load
modify
cmpxchg
Notice that the cmpxchg-based case does _not_ get any worse - in fact
it's exactly identical. Note, however, that the llsc case becomes
more efficient.
True in many cases. However in a lock fastpath one could do the
atomic_cmpxchg without an initial load, assuming the lock is
unlocked.
atomic_cmpxchg(&lock, UNLOCKED, LOCKED)
which should basically wind up to the most optimal code on both the
cmpxchg and ll/sc platforms (aside from other quirks David pointed
out like cmpxchg being worse than lock inc on x86).
Ah - I see you pointed out "for general consumption", I missed that.
Indeed for general consumption one should still be careful using
atomic_cmpxchg.
Nick
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
