hi, Yes if config CONFIG_PREEMPT enabled,even if you dont have an smp box,we can think of preemption as equivalent to SMP.correct me if i am wrong about below lockings if we require locking only in user context: semaphore is preferred locking between user context(can be kernelpath) and sofirqs:spin_lock_bh() and spin_unlock_bh() locking between user context and tasklets:spin_lock_bh() and spin_unlock_bh() locking between user context and timers:spin_lock_bh() and spin_unlock_bh() locking between two same tasklets or same timers: not required locking between two different tasklets or different timers or tasklet/timer: spin_lock,spin_unlock locking between same softirqs: spin_lock,spin_unlock locking between different softirqs: spin_lock,spin_unlock locking between hardirq and softirq: spin_lock_irqsave,spin_unlock_irqrestore locking between two hardirq : spin_lock_irqsave thanks, karunakar On Thu, Nov 10, 2011 at 11:17 AM, Rajat Sharma <fs.rajat@xxxxxxxxx> wrote: > 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 > _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
