Spinlocks and interrupts

[karuna.linux@gmail.com (santhosh kumars)]

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