Jeff V. Merkey wrote:
> However, the issues raised relative to the cross platform lock/irq
> function semantics raised by folks are significant. Typically on
> Intel, you want to disable interrupts around a spinlock/unlock pair for
> any code paths that can be re-entered via an interrupt, timer, etc.
> Most spinlock implementations I've seen may also enable interrupts while
> they are spining, then disable them inside the lock
Hmm, that's a nice idea. Does it improve performance?
> ... to avoid deadlocks caused by an interrupt breaking into a code
> section holding the spinlock because interrupts were enabled.
> Whatever semantic is used, however, should be general enough to allow:
>
> ints_off()
> spinlock()
>
> spinunlock()
> ints_on()
>
> or something to that effect for all the SMP capable architectures. :-)
spin_lock() should leave the irq state well alone, whether it spins or
not. The only thing that may be interesting to change is
spin_lock_irqsave() -- that could be made to behave "as if" interrupts
are not disabled until the moment the lock is actually acquired.
(I.e. by restoring the irq state while spin-reading).
I don't know if there are any performance gains, or fairness issues that
may arise. But as far as lock safety goes, that is perfectly safe. It
simply changes the timing.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:17 EST