On 06 Oct 2009, at 9:59 AM, Jason Nymble wrote:
On 06 Oct 2009, at 9:03 AM, er krishna wrote:
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 ?
Maybe this will shed some light:
http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/c214.html
There are also other options to consider, such as deferring the
interrupt handler work to a workqueue or tasklet, and performing the
appropriate synchronization there instead of in the interrupt handler
itself (this might allow you to for instance use a semaphore or
spin_lock_bh instead of spin_lock_irq). Also, depending on what you
need to do, you might be able to refactor your code to use lockless
algorithms or data structures, such as single producer single consumer
ring FIFO (e.g. see kfifo.h, specifically __kfifo_put and __kfifo_get)
or atomic variables.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ