Re: Spinlocks and interrupts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Kai,

On Wed, Nov 9, 2011 at 1:07 PM, Kai Meyer <kai@xxxxxxxxxx> wrote:
> When I readup on spinlocks, it seems like I need to choose between
> disabling interrupts and not. If a spinlock_t is never used during an
> interrupt, am I safe to leave interrupts enabled while I hold the lock?
> (Same question for read/write locks if it is different.)

So the intention behind using a spinlock is to provide mutual exclusion.

A spinlock by itself only really provides mutual exclusion between 2
cores, and not within the same core. To provide the mutual exclusion
within the same core, you need to disable interrupts.

Normally, you would disable interrupts and acquire the spinlock to
guarantee that mutual exclusion, and the only reason you would
normally use the spinlock without disabling interrupts is when you
know that interrupts are already disabled.

The danger of acquiring a spinlock with interrupts enabled is that if
another interrupt fired (or the same interrupt fired again) and it
tried to acquire the same spinlock, then you could have deadlock.

If no interrupts touch the spinlock, then you're probably using the
wrong mutual exclusion mechanism. spinlocks are really intended to
provide mutual exclsion between interrupt context and non-interrupt
context.

Also remember, that on a non-SMP (aka UP) build, spinlocks become
no-ops (except when certain debug checking code is enabled).

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux