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).
>
next prev parent 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).