public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "BALBIR SINGH" <balbir.singh@wipro.com>
To: "Paul E. McKenney" <pmckenne@us.ibm.com>
Cc: lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: RFC: patch to allow lock-free traversal of lists with insertion
Date: Tue, 09 Oct 2001 12:43:55 +0530	[thread overview]
Message-ID: <3BC2A3B3.3020004@wipro.com> (raw)
In-Reply-To: <200110090155.f991tPt22329@eng4.beaverton.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 2580 bytes --]


Paul E. McKenney wrote:

>Request for comments...
>
>This is a proposal to provide a wmb()-like primitive that enables
>lock-free traversal of lists while elements are concurrently being
>inserted into these lists.
>
>This is already possible on many popular architectures, but not on
>
>some CPUs with very weak memory consistency models.  See:
>
>	http://lse.sourceforge.net/locking/wmbdd.html
>
>for more details.
>
>I am particularly interested in comments from people who understand
>the detailed operation of the SPARC membar instruction and the PARISC
>SYNC instruction.  My belief is that the membar("#SYNC") and SYNC
>instructions are sufficient, but the PA-RISC 2.0 Architecture book by
>Kane is not completely clear, and I have not yet received my copy of
>the SPARC architecture manual.
>
>Thoughts?
>

1) On Alpha this code does not improve performance since we end up using spinlocks
for my_global_data anyway, I think you already know this. I am a little confused
with the code snippet below


+       spin_lock_irqsave(&mb_global_data.mutex, flags); /* implied mb */
+       if ((mb_global_data.need_mb & this_cpu_mask) == 0) {
+               spin_unlock_irqrestore(&mb_global_data.mutex, flags);
+               return;
+       }
+       mb_global_data.need_mb &= this_cpu_mask;
+ 	if (mb_global_data.need_mb == 0) {
+               if (++mb_global_data.curgen - mb_global_data.maxgen <= 0) {
+                       mb_global_data.need_mb = to_whom;
+                       send_ipi_message(to_whom, IPI_MB);
+               }
+       }
+       spin_unlock_irqrestore(&mb_global_data.mutex, flags); /* implied mb */

Are we not checking for the same thing in 
		(mb_global_data.need_mb &am
p; this_cpu_mask) == 0

and in
		mb_global_data.need_mb &= this_cpu_mask;
		if (mb_global_data.need_mb == 0) {

In case 1 we return, but in case two we increment the curgen and if curgen is less than
or equal to maxgen then we send IPI's again.

2) What are the rules for incrementing or changing the generation numbers curgen, mygen and
maxgen in your code?

The approach is good, but what are the pratical uses of the approach. Like u mentioned a newly
added element may not show up in the search, searches using this method may have to search again
and there is no way of guaranty that an element that we are looking for will be found (especially
if it is just being added to the list).

The idea is tremendous for approaches where we do not care about elements being newly added.
It should definitely be in the Linux kernel  :-) 


Balbir

>
>
>						Thanx, Paul
>


[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 853 bytes --]

----------------------------------------------------------------------------------------------------------------------
Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and
is intended for use only by the individual or entity to which it is
addressed, and may contain information that is privileged, confidential or
exempt from disclosure under applicable law. If you are not the intended
recipient or it appears that this mail has been forwarded to you without
proper authority, you are notified that any use or dissemination of this
information in any manner is strictly prohibited. In such cases, please
notify us immediately at mailto:mailadmin@wipro.com and delete this mail
from your records.
----------------------------------------------------------------------------------------------------------------------


  parent reply	other threads:[~2001-10-09  7:13 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-09  1:55 RFC: patch to allow lock-free traversal of lists with insertion Paul E. McKenney
2001-10-09  2:18 ` David S. Miller
2001-10-09  6:52 ` Richard Henderson
2001-10-09  9:03   ` Rusty Russell
2001-10-09 16:11     ` Richard Henderson
2001-10-10  1:39       ` Rusty Russell
2001-10-09  7:13 ` BALBIR SINGH [this message]
2001-10-09  7:46   ` Dipankar Sarma
2001-10-09  8:21     ` BALBIR SINGH
2001-10-09  8:48       ` Dipankar Sarma
  -- strict thread matches above, loose matches on Subject: below --
2001-10-09  5:27 Paul McKenney
2001-10-09  5:56 ` David S. Miller
2001-10-09  6:43   ` Richard Henderson
2001-10-09 15:24 Paul McKenney
2001-10-09 15:28 Paul McKenney
2001-10-09 15:45 Paul McKenney
2001-10-09 17:00 ` Richard Henderson
2001-10-10  3:33   ` Paul Mackerras
2001-10-10 17:02     ` Richard Henderson
2001-10-09 16:51 Manfred Spraul
2001-10-09 17:46 Paul McKenney
2001-10-09 18:01 Paul McKenney
2001-10-10  1:19 Paul McKenney
2001-10-10  1:43 ` Andrea Arcangeli
2001-10-10 21:47 Paul McKenney
2001-10-10 22:22 ` Richard Henderson
2001-10-10 22:27 ` Richard Henderson
2001-10-11  1:56 Paul E. McKenney
2001-10-12  4:14 ` Rusty Russell
2001-10-13 14:48   ` Paul E. McKenney

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=3BC2A3B3.3020004@wipro.com \
    --to=balbir.singh@wipro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=pmckenne@us.ibm.com \
    /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