On Wed, Oct 7, 2009 at 12:04 PM, Jason Nymble <jason.nym...@gmail.com>wrote:
> > 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 <rajat.j...@infogain.com>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. > Just asking, spin_lock will disable preemption, but it can't disable interrupts. So, a higher priority process can't preempt lower priority process. Second, Interrupts are nothing to do with preemption. Interrupt handlers can preempt a process unless it is not disable ( of course via spin_lock_irq or spin_lock_irq_save api). > 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... >
