All of lore.kernel.org
 help / color / mirror / Atom feed
From: kai@gnukai.com (Kai Meyer)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Spinlocks and interrupts
Date: Wed, 09 Nov 2011 16:12:20 -0700	[thread overview]
Message-ID: <4EBB08D4.3010205@gnukai.com> (raw)
In-Reply-To: <CABi1daHqFFTVsFWtF2EuTWPq6tYQk7r=41kqy2+X8DyB2LyLPQ@mail.gmail.com>

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@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).
>

  reply	other threads:[~2011-11-09 23:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-09 21:07 Spinlocks and interrupts Kai Meyer
2011-11-09 21:40 ` Dave Hylands
2011-11-09 23:12   ` Kai Meyer [this message]
2011-11-10  0:03     ` Jeff Haran
2011-11-10  3:38     ` Dave Hylands
2011-11-10 17:02       ` Kai Meyer
2011-11-10 18:02         ` Kai Meyer
2011-11-10 18:14           ` Kai Meyer
2011-11-10 19:07             ` Dave Hylands
2011-11-10 19:19               ` Jeff Haran
2011-11-10 21:55                 ` Kai Meyer
2011-11-10 23:00                   ` Jeff Haran
2011-11-10 23:20                     ` Kai Meyer
2011-11-11  6:58                       ` Rajat Sharma
2011-11-14 19:05                         ` Kai Meyer
2011-11-10  4:47   ` rohan puri
2011-11-10  5:47     ` Rajat Sharma
2011-11-10 10:05       ` santhosh kumars

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EBB08D4.3010205@gnukai.com \
    --to=kai@gnukai.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.