If a data structure is being accessed both by an interrupt handler and a process / thread / in kernel mode then you might have to go for spin locks with kernel preemption disabled.
What happens when you go for spin locks without disabling kernel preemption? Suppose you acquire a spin lock in a system call handler (a service routine on behalf of a user mode process) with kernel preemption enabled. When an interrupt handler comes it will preempt the current process and try to acquire a spinlock. A DEADLOCK! You can't go for semaphores either since implementation of semaphore would suspend the process and in an interrupt handler there is no way to no the context of a process. Though I believe recent kernel versions do implement semaphores without suspending the process. I guess you can use these constructs inside interrupt handlers. To some extent answer to your question also depends on where the critical section code is? a) If it's in an exception handler then it's always better to go for spinlocks with kernel preemption disabled If interrupt handler is also accessing the same data structure b) If it's in an interrupt handler then you will have to go for spin locks with interrupts disabled. Hope this helps. Thanks. -Govindraj On Tue, 06 Oct 2009 12:44:51 +0530 wrote >Dear All,I have a very basic confusion, please help and confirm the right >answer :If a process/thread (user space/kernel space) has taken a lock on a >critical section code, and suddenly an interrupt occurs which want to use the >same shared data of critical region. Will it able to preempt this code which >is running in process context ? As per my understanding, although interrupts has higher priority than process, but it can't preempt the process otherwise a major bug can occur ( depending upon the shared data of critical section). Please confirm my understanding weather its true or not ? Best regards,Krishna
