kernelnewbies.kernelnewbies.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).