Spinlocks and interrupts

[Kai Meyer]

Ok, I need mutual exclusion on a data structure regardless of interrupts 
and core. It sounds like it can be done by using a spinlock and 
disabling interrupts, but you mention that "spinlocks are intended to 
provide mutual exclsion between interrupt context and non-interrupt 
context." Should I be using a semaphore (mutex) instead?

Perhaps I could explain my problem with some code:
struct my_struct *get_data(spinlock_t *mylock, int ALLOC_DATA)
{
     struct my_struct *mydata = NULL;
     spin_lock(mylock);
     if (test_bit(index, mybitmap))
             mydata = retrieve_data();
     if (!mydata && ALLOC_DATA) {
             mydata = alloc_data();
             set_bit(index, mybitmap);
     }
     spin_unlock(mylock);
     return mydata;
}

I need to prevent retrieve_data from being called if the index bit is 
set in mybitmap and alloc_data has not completed, so I use a bitmap to 
indicate that alloc_data has completed. I also need to protect 
alloc_data from being run multiple times, so I use the spin_lock to 
ensure that test_bit (and possibly retrieve_data) is not run while 
alloc_data is being run (because it runs while the bit is cleared).

-Kai Meyer


On 11/09/2011 02:40 PM, Dave Hylands 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).
>