hi Krishna , i will hazard and answer here.AFAIK , it will depend on 2 things. 1> if the code which the interrupt handler executed is running under a context of a higher priority process , then priority inversion may take place and the code currently holding the critical section completes first and then the higher priority process runs . 2> if the new process is of a lower priority , it is blocked in the waitQ of the lock. My reply is based on a conceptual information and i am NOT SURE if this happens in the current kernel or not i request others to tell me if my understanding is correct .
BR Rahul Ramasubramanian On Tue, Oct 6, 2009 at 3:03 AM, er krishna <erkris...@gmail.com> 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 > >
