On Tue, Oct 6, 2009 at 1:22 PM, debian developer <debiandev@xxxxxxxxx> wrote: > On Tue, Oct 6, 2009 at 12:33 PM, 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 ? >> > You are right. If a lock is held, the process cannot be pre-empted by an > interrupt which is going to use the same shared data held under lock. > > The interrupt may be scheduled later or might be lost. > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx > Please read the FAQ at http://kernelnewbies.org/FAQ > > No I guess what Krishna want to ask is that if some data is shared between user context and interrupt context then is it possible that isr can start using that data even user context is already in critical region. Answer is yes. Thats why you will have to use interrupt-safe locking like spin_lock_irqsave(). Please read a very nice and popular documentation about locking, "Unreliable Guide To Locking" http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/ -Vinit -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
