Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: [RFC] New locking primitive for 2.5 | Date | Thu, 7 Feb 2002 20:33:15 +0100 |
| |
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/
| |