On Thu, Nov 10, 2011 at 3:10 AM, Dave Hylands <[email protected]> wrote:
> Hi Kai, > > On Wed, Nov 9, 2011 at 1:07 PM, Kai Meyer <[email protected]> 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 > [email protected] > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > Nice explanation Dave. Regards, Rohan Puri
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
