Messages in this thread | | | Date | Thu, 6 Jul 2000 01:00:43 +0200 | From | Jamie Lokier <> | Subject | Re: spinlocks() are severely broken in 2.2.X and 2.4.X for modules |
| |
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/
| |