Messages in this thread | | | Date | Sat, 09 Dec 2006 09:33:10 +1100 | From | Nick Piggin <> | Subject | Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it |
| |
Russell King wrote: > On Fri, Dec 08, 2006 at 12:18:52PM +1100, Nick Piggin wrote: > >>Russell King wrote: >> >>>On Thu, Dec 07, 2006 at 08:31:08PM +1100, Nick Piggin wrote: >> >>>>>Implementing ll/sc based accessor macros allows both ll/sc _and_ cmpxchg >>>>>architectures to produce optimal code. >>>>> >>>>>Implementing an cmpxchg based accessor macro allows cmpxchg architectures >>>>>to produce optimal code and ll/sc non-optimal code. >>>>> >>>>>See my point? >>>> >>>>Wrong. Your ll/sc implementation with cmpxchg is buggy. The cmpxchg >>>>load_locked is not locked at all, >>> >>> >>>Intentional - cmpxchg architectures don't generally have a load locked. >> >>Exactly, so it is wrong -- you can't implement that behaviour with >>load + cmpxchg. > > > I disagree. I _have_ implemented the required behaviour. I really > don't understand your point saying that it is wrong. > > >>>>and there can be interleaving writes >>>>between the load and cmpxchg which do not cause the store_conditional >>>>to fail. >>> >>> >>>In which case the cmpxchg fails and we do the atomic operation again, >>>in exactly the same way that we do the operation again if the 'sc' >>>fails in the ll/sc case. >> >>Not if cmpxchg sees the same value, it won't fail, regardless of how >>many writes have hit that memory address. > > > Don't see anything wrong with that. If that was a problem, atomic > implementations using cmpxchg on x86 would be impossible. > > I think you're trying to implement ll/sc semantics on CPUs without > ll/sc which is exactly not what I'm trying to do. I'd argue that's > impossible.
Yes, I did think that from reading your emails. It is not a problem as such, but it is important to be clear on semantics.
> I'm trying to suggest a better implementation for atomic ops rather > than just bowing to this x86-centric "cmpxchg is the best, everyone > must implement it" mentality.
Even if ARM is able to handle any arbitrary C code between the "load locked" and store conditional API, other architectures can not by definition.
-- 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/
| |