All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.