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 <erkrishna@xxxxxxxxx> 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
