From: Parag Warudkar <kernel-stuff@comcast.net>
To: Anton Altaparmakov <aia21@cam.ac.uk>
Cc: Imanpreet Singh Arora <imanpreet@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Question from Russells Spinlocks
Date: Thu, 09 Dec 2004 21:02:36 -0500 [thread overview]
Message-ID: <41B903BC.3020208@comcast.net> (raw)
In-Reply-To: <Pine.LNX.4.60.0412092326260.2294@hermes-1.csi.cam.ac.uk>
Anton Altaparmakov wrote:
>On Thu, 9 Dec 2004 kernel-stuff@comcast.net wrote:
>
>
>>Spinlocks are used in situations where multiple threads contend for a
>>lock and they can possibly run on more than one CPU. Example - Thread A
>>is executing on CPU-A, Thread B in executing on CPU-B. They contend for
>>a lock L1. A acquires the lock first. B tries (on CPU-B) to acquire the
>>lock L1 and finds it is not free - so it just spins (executes a no-op
>>kind of loop ) until Thread A relinquishes the lock L1. Spinlocks are
>>used in cases where the operation performed under a lock is short one -
>>takes very less time. In these type of cases, spinning is less costlier
>>than sleeping which involves scheduler overhead. So if we take out CPU-B
>>from the above equation - there is no chance for Thread B to execute to
>>contend for lock L1 without thread A going to sleep. That's why
>>spinlocks are useless on 1 CPU machine.
>>
>>
>
>Your last sentence is incorrect. Spinlocks on 1 CPU machines still need
>to disable preemption (assuming preemption is compiled in obviously, if
>not then indeed you are right). Otherwise preemption could take place in
>the middle of a data manipulation and you would still have the same race
>as you described with two cpus working concurrently. Except that with
>preemption it is only logical concurrence not actual physical concurrence.
>
>
I didn't take pre-emption into account. Although I would not have
readily thought about the need to disable Pre-emption even if I had
considered it :-) So thanks for the correction!
Parag
next prev parent reply other threads:[~2004-12-10 2:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-09 21:15 Question from Russells Spinlocks kernel-stuff
2004-12-09 21:49 ` Robert Love
2004-12-10 2:04 ` Parag Warudkar
2004-12-09 23:30 ` Anton Altaparmakov
2004-12-09 23:58 ` Jeff V. Merkey
2004-12-10 2:02 ` Parag Warudkar [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-12-08 21:00 Imanpreet Singh Arora
2004-12-09 21:53 ` Brian Gerst
2004-12-09 22:03 ` William Lee Irwin III
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=41B903BC.3020208@comcast.net \
--to=kernel-stuff@comcast.net \
--cc=aia21@cam.ac.uk \
--cc=imanpreet@gmail.com \
--cc=linux-kernel@vger.kernel.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.