lkml.org 
[lkml]   [2005]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
    David Howells wrote:

    >>It is not even clear that any ll/sc based architectures would need to override
    >>an atomic_cmpxchg variant at all because you can assume an unlocked fastpath
    >
    >
    > That's irrelevant. Any arch that has LL/SC almost certainly emulates CMPXCHG
    > with LL/SC.
    >

    It is not irrelevant because many architectures that would care are ll/sc
    based and many others have a native cmpxchg ie. cmpxchg wouldn't be a bad
    choice for default.

    >
    >>and not do the additional initial load to prime the cmpxchg.
    >
    >
    > Two points:
    >
    > (1) LL/SC does not require an additional initial load.
    >

    ?? I was only talking about cmpxchg

    > (2) CMPXCHG does an implicit load; how else can it compare?
    >

    Read Russell's posts. He points out that most usages of cmpxchg
    will require an additional load compared with an llsc in order to
    find the value to work on.

    cmpxchg(lock, UNLOCKED, LOCKED)

    does not (although it may still require an extra branch).

    --
    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/

    \
     
     \ /
      Last update: 2005-12-17 00:44    [W:7.210 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site