lkml.org 
[lkml]   [2006]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Why Semaphore Hardware-Dependent?
    Date
    On Sunday 27 August 2006 21:22, Dong Feng wrote:
    > Why can't we have a hardware-independent semaphore definition while we
    > have already had hardware-dependent spinlock, rwlock, and rcu lock? It

    We probably could yes, if up/down were out of lined. The only
    reason it is assembly code is that it uses still funky assembly
    to get a fast uncontended fast path. Since out of lining
    worked for spinlocks it will likely work for semaphores too.

    > seems the semaphore definitions classified into two major categories.
    > The main deference is whether there is a member variable _sleeper_.
    > Does this (optional) member indicate any hardware family gene?

    AFAIK the normal semaphores all work basically the same over the
    architectures, just the calling conventions are different. If it was
    pure out of line C that wouldn't be a problem anymore.

    rwsems don't -- there are two flavours: a generic spinlock'ed one and a
    complicated atomic based one that only works on some architectures.
    As far as I know nobody has demonstrated a clear performance increase
    from the first so it might be possible to switch all to the generic
    implementation.

    If you're interested in this you should probably do patches and benchmarks.

    -Andi
    -
    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: 2006-08-27 22:57    [W:4.132 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site