lkml.org 
[lkml]   [2008]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: spinlocks -- why are releases inlined and acquires are not?
    On Tue, 1 Apr 2008, Jiri Kosina wrote:

    > What is the reason for this asymetry? Shouldn't the acquiring functions
    > be implemented in the very same way? Or at least, shouldn't all the
    > __lockfunc functions be inlined?

    i.e. is there any particular reason why we don't have something like the
    patch below (implemented for all the lock variants of course, this is
    just to demonstrate what I mean)?


    spinlocks: inline spin_lock() in non-debug cases

    inline spin_lock() in the non-debug case.

    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

    diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
    index 576a5f7..30922ba 100644
    --- a/include/linux/spinlock.h
    +++ b/include/linux/spinlock.h
    @@ -178,7 +178,12 @@ do { \
    #define read_trylock(lock) __cond_lock(lock, _read_trylock(lock))
    #define write_trylock(lock) __cond_lock(lock, _write_trylock(lock))

    +#if defined(CONFIG_DEBUG_SPINLOCK) || defined(CONFIG_PREEMPT) || \
    + !defined(CONFIG_SMP)
    #define spin_lock(lock) _spin_lock(lock)
    +#else
    +#define spin_lock(lock) \
    + do { __raw_spin_lock(&(lock)->raw_lock); __acquire(lock); } while (0)

    #ifdef CONFIG_DEBUG_LOCK_ALLOC
    # define spin_lock_nested(lock, subclass) _spin_lock_nested(lock, subclass)

    \
     
     \ /
      Last update: 2008-04-01 02:43    [W:0.054 / U:121.792 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site