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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• References:
  • [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it
    • From: David Howells <[email protected]>
  • Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it
    • From: Christoph Lameter <[email protected]>
  • Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it
    • From: Russell King <[email protected]>
  • Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it
    • From: Christoph Lameter <[email protected]>
  • Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it
    • From: Russell King <[email protected]>
  • Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it
    • From: Nick Piggin <[email protected]>
  • Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it
    • From: Russell King <[email protected]>
  • Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it
    • From: Nick Piggin <[email protected]>
  • Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it
    • From: Russell King <[email protected]>

• Prev by Date: Re: [patch 1/2] agpgart - allow user-populated memory types.
• Next by Date: Re: [PATCH 2/6] e1000: use pcix_set_mmrbc
• Previous by thread: Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it
• Next by thread: Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]