On 07 Oct 2009, at 7:47 AM, er krishna wrote:
Rajat San,
Just asking (since i didn't see spinlock implementation in kernel
src),
On Tue, Oct 6, 2009 at 5:52 PM, Rajat Jain <[email protected]>
wrote:
Hello Govind,
> What happens when you go for spin locks without
> disabling kernel preemption? Suppose you acquire
> a spin lock in a system call handler (a service
> routine on behalf of a user mode process) with
> kernel preemption enabled.
This is not possible. Spin lock APIs disable kernel preemption
automatically.
Spin lock APIs disables kernel preemption in all its api or some
specific apis only. Please confirm and elaborate.
There are a few variants of the spin lock APIs. See the link which
various people have posted for details:
http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/index.html
The most basic spin_lock() does not disable scheduling or interrupts
etc., so must be avoided for synchronization between a syscall and an
interrupt context otherwise you will get deadlock. spin_lock_irqsave()
disables all pre-emptive scheduling and interrupts AFAIK, so it would
be safe. I think it is generally preferable to avoid using
spin_lock_irqsave() if possible by deferring your interrupt work to a
tasklet (in which you can use spin_lock_bh to sync to your syscall) or
a workqueue (in which you can use a semaphore to sync to your
syscall). Even better would be to use lockless algorithms or data
structures if possible. In general, if you must use a spinlock, try to
keep it limited to a very small piece of code to reduce lock
contention. Also, enable kernel debugging and specifically the options
about lock checking, these can help a great deal to debug issues. I
hope the aforementioned information is correct and doesn't lead you
astray...
