lkml.org 
[lkml]   [2002]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC] New locking primitive for 2.5
    Date
    On February 7, 2002 07:22 pm, Christoph Hellwig wrote:
    > In article <3C629F91.2869CB1F@dlr.de> you wrote:
    > > If a spin_lock request is blocked by a mutex_lock call, the spin_lock
    > > attempt also sleeps i.e. behaves like a semaphore.
    > > If you gained ownership of the lock, you can switch between spin-mode
    > > and mutex-(ie.e sleeping) mode by calling:
    > >
    > > combi_to_mutex_mode(struct combilock *x)
    > > combi_to_spin_mode(struct combilock *x)
    > >
    > > without loosing the lock. So you may start with a spin-lock and relax
    > > to a sleeping lock if for example you need to call a non-atomic kmalloc.
    >
    > This looks really ugly. I'd really prefer an automatic fallback from
    > spinning to sleeping after some timeout like e.g. solaris adaptive
    > mutices.

    Look closer at what he said. You'd take the lock, then you might decide you
    had to do something on a slow/blocking path, for example, a copy to/from user,
    so you could do that without leaving waiters spinning, or having to
    acquire a different lock and re-establish the state. It bears thinking
    about.

    --
    Daniel
    -
    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-03-22 13:24    [W:3.947 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site