Messages in this thread | | | Date | Sat, 17 Dec 2005 00:41:31 +1100 | From | Nick Piggin <> | Subject | Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |