On Tue, Oct 6, 2009 at 3:16 PM, vinit dhatrak <vinit.dhatrak@xxxxxxxxx> wrote: > 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 > Sorry didnt notice previous replies. Many ppl has already replied with similar explanation :) -Vinit -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
