Sorin Manolache wrote:
The Linux Device Drivers book says that a spin_lock should not be shared between a process and an interrupt handler. The explanation is that the process may hold the lock, an interrupt occurs, the interrupt handler spins on the lock held by the process and the system freezes. Why should it freeze? Isn't it possible for the interrupt handler to re-enable interrupts as its first thing, then to spin at the lock, the timer interrupt to preempt the interrupt handler and to relinquish control to the process which in turn will finish its critical section and release the lock, making way for the interrupt handler to continue.
When the timer interrupt finishes, it's not going to return control to the process, it's going to return control to what it interrupted which is the interrupt handler in your code which will just continue spinning. Interrupt handlers are not preemptible by anything other than other interrupt handlers (and then only in some cases) so it will sit spinning on that lock forever.
-- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/