[RFC] New locking primitive for 2.5

[Martin Wirth <martin.wirth@epost.de>]

Christoph Hellwig  wrote:
> I think this API is really ugly.  If both pathes actually do the same,
> just with different defaults, one lock function with a flag would be
> much nicer.  
Just to use plain numbers is not very instructive, so you ask for a
macro 
definition like COMBI_LOCK_SPIN_MODE ????? 


> Also why do we need two unlock functions?
There is the generic_unlock function, if you forgot in which mode you
are.
The main reason is performance for the spin mode: combi_spin_unlock is
just
a spin_unlock, no test, no branch. So you are faster if you know what
you did
a few lines of code before ;-)


Robert Love 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:
> 
> This can be bad.  What if I grab a spinlock in a codepath where only a
> spinlock is appropriate (i.e. somewhere I can't sleep, like an irq
> handler) -- and then I sleep?

As noted in my initial e-mail the current implementation is not for
use in irq-handlers or BHs etc. 
> 
> > Open questions:
> >
> >   * Does it make sense to also provide irq-save versions of the
> >     locking functions? This means you could use the unlock functions
> >     from interrupt context. But the main use in this situation is
> >     completion handling and there are already (new) completion handlers
> >     available. So I don't think this is a must have
> 
> You can't sleep in an interrupt request handler\x03, so this wouldn't make a
> lot of sense.

You of course were only allowed to call the unlock() functions!!
Therefore you could use them to free a resource from the handler
(but that's very much completion handling, see above).

> We shouldn't engage in wholesale changing of spinlocks to semaphores
> without a priority-inheritance mechanism.  And _that_ is the bigger
> issue ...

The combilock at least can be used to narrow the time windows for
priority
inversion because for most purposes you would use the spin mode. I
thinking
about some extension in this direction (that's why the owner field is a
pointer
to the owning task btw.).



> As for combi lock itself, it would be great, if it were possible to
> detect whether lock is held by thread running on the same CPU and sleep
> if so. This would allow for implementing interrupts as separate threads,
> etc.

That the e.g. the aproach of Solaris which results in about 5 time
higher 
latencies from a hardware interrupt to the waiting process.


    Martin Wirth