Hi,
> Many architectures do not have atomicity guarantees in SMP: you may end up
> getting the same interrupt twice on two CPU's. The spinlock handles that
> case too.
I have an idea for a recursive spinlock, that I want to try, basically
it looks:
if (lock) {
if (lock != current) {
while (lock)
;
}
}
lock = current;
This has to be done of course atomically, so that I need the cmpxchg
instruction here. But it offers a very nice and cheap way for drivers to
make them smp safe if they not totally screwed up (so that they even
need for UP interrupts disabled).
> Feel free to try it. It was discussed, but it's not trivial to do
> correctly. You get the IRQ_PENDING problem even more clearly (ie it
> becomes a problem even with well-designed interrupt controllers).
Let's say I try something for 2.5, I even can test it on a SMP system (I
only have to get the backup running before :) ).
Anyway, my main concern is that a generic interrupt handling would put
some synchronisation requirements on architectures, that don't really need
them. E.g. on most m68k system you can jump straight to the interrupt
handler, although we don't need to worry about SMP, but we also wouldn't
need to worry about reentrancy, if interrupt handler weren't allowed to
play with the interrupt context.
bye, Roman
-
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 : Tue Mar 07 2000 - 21:00:09 EST