Spinlocks and interrupts

[Rajat Sharma]

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 at gmail.com> wrote:
>
>
> On Thu, Nov 10, 2011 at 3:10 AM, Dave Hylands <dhylands at gmail.com> wrote:
>>
>> Hi Kai,
>>
>> On Wed, Nov 9, 2011 at 1:07 PM, Kai Meyer <kai at 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
>
>