Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation

Nick Piggin
2005-12-16T13:41:31Z

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