Hi Dave, > Also, remember that spin-locks are no-ops on a single processor > machine, so as coded, you have no protection on a single-processor > machine if you're calling from thread context. Not completely true, spinlock can still provide protection even in this case i.e. two thread context sharing a resource on UP. Remember that for peemptive kernel, it disables preemption, so it is guranteed that scheduler does not through out this thread as long as spinlock is held. I agree that a mutex can as well be used for this example but it again depends on situation, if you want to be quick about your task and are 100% sure that task does not sleep or takes too long processing cycles, disabling preemption (i.e. spinlock in this case) can be a better option. Thanks, Rajat On Thu, Nov 10, 2011 at 10:17 AM, rohan puri <rohan.puri15@xxxxxxxxx> wrote: > > > On Thu, Nov 10, 2011 at 3:10 AM, Dave Hylands <dhylands@xxxxxxxxx> wrote: >> >> 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 > > Nice explanation Dave. > > Regards, > Rohan Puri > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@xxxxxxxxxxxxxxxxx > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
