Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming.threads > #2488 > unrolled thread

I was asked a question by Chris Thomasson 1

Started byaminer <aminer@toto.net>
First post2014-06-11 04:54 -0700
Last post2014-06-14 12:49 -0700
Articles 5 — 3 participants

Back to article view | Back to comp.programming.threads


Contents

  I was asked a question by Chris Thomasson 1 aminer <aminer@toto.net> - 2014-06-11 04:54 -0700
    Re: I was asked a question by Chris Thomasson 1 aminer <aminer@toto.net> - 2014-06-11 05:03 -0700
      Re: I was asked a question by Chris Thomasson 1 "Chris M. Thomasson" <no@spam.invalid> - 2014-06-14 11:49 -0700
        Re: I was asked a question by Chris Thomasson 1 Ramine <ramine@1.1> - 2014-06-14 12:37 -0700
        Re: I was asked a question by Chris Thomasson 1 Ramine <ramine@1.1> - 2014-06-14 12:49 -0700

#2488 — I was asked a question by Chris Thomasson 1

Fromaminer <aminer@toto.net>
Date2014-06-11 04:54 -0700
SubjectI was asked a question by Chris Thomasson 1
Message-ID<lnaflc$gbg$4@news.albasani.net>
Hello,


I was asked a question by Chris Thomasson on comp.programming.threads, 
he asked why i have said that my scalable RWLocks algorithms are as
scalable as RCU and quiescent-state based reclamation (QSBR)
on the following IEEE paper on read mostly scenarios:

Here is the IEEE paper:

https://www.efficios.com/pub/rcu/urcu-main.pdf


Here is my answer:

You have to know that RCU and quiescent-state based reclamation (QSBR)
on the above IEEE parpers are scalable on the reader side cause
they don't use expensive atomic operations on the reader side, but
what i have just explained to you that my scalable RWLocks are also
scalable on the reader side, cause they don't use expensive atomic 
operations on the reader side, in fact my sclable RWLocks algorithms 
don't generate expensive cache-lines transfers on the reader side, so 
this why i have said that on read mostly operations scenarios my 
scalable RWLocks are as scalable as RCU of the above IEEE paper and as 
scalable as  quiescent-state based reclamation (QSBR) of the above IEEE 
paper.

I have done some empiric statistics with some benchmarks and i have
noticed that my scalable RWLocks scales even at 3% of writes.



Thank you,
Amine Moulay Ramdane.




[toc] | [next] | [standalone]


#2489

Fromaminer <aminer@toto.net>
Date2014-06-11 05:03 -0700
Message-ID<lnag6l$hm7$2@news.albasani.net>
In reply to#2488
On 6/11/2014 4:53 AM, aminer wrote:> Hello,
 >
 >
 > I was asked a question by Chris Thomasson on comp.programming.threads,
 > he asked why i have said that my scalable RWLocks algorithms are as
 > scalable as RCU and quiescent-state based reclamation (QSBR)
 > on the following IEEE paper on read mostly scenarios:
 >
 > Here is the IEEE paper:
 >
 > https://www.efficios.com/pub/rcu/urcu-main.pdf
 >
 >
 > Here is my answer:
 >
 > You have to know that RCU and quiescent-state based reclamation (QSBR)
 > on the above IEEE parpers are scalable on the reader side cause
 > they don't use expensive atomic operations on the reader side, but
 > what i have just explained to you that my scalable RWLocks are also
 > scalable on the reader side, cause they don't use expensive atomic
 > operations on the reader side, in fact my sclable RWLocks algorithms
 > don't generate expensive cache-lines transfers on the reader side,

I must be more precise:

I mean that when there is no writes, my scalable algorithms don't 
generate expensive cache-lines transfers on the reader side, this is why 
my scalable RWLocks algorithms are scalable on read mostly
scenarios.

I have done some empiric statistics with some benchmarks and i have
noticed that my scalable RWLocks scale even at 3% of writes.



Hope you have understood.


 >so
 > this why i have said that on read mostly operations scenarios my
 > scalable RWLocks are as scalable as RCU of the above IEEE paper and as
 > scalable as  quiescent-state based reclamation (QSBR) of the above IEEE
 > paper.
 >
 > I have done some empiric statistics with some benchmarks and i have
 > noticed that my scalable RWLocks scales even at 3% of writes.
 >
 >
 >
 > Thank you,
 > Amine Moulay Ramdane.
 >
 >
 >
 >
 >
 >
 >

[toc] | [prev] | [next] | [standalone]


#2505

From"Chris M. Thomasson" <no@spam.invalid>
Date2014-06-14 11:49 -0700
Message-ID<lni5fa$5aq$1@speranza.aioe.org>
In reply to#2489
> "aminer"  wrote in message news:lnag6l$hm7$2@news.albasani.net... 
> [...]

IMVHO, you do not seem understand why RCU beats a non-asymmetric
rw-lock. Besides that, how can you compare RCU with a read-write mutex
when RCU allows reads and writes to occur concurrently?

Can a write proceed when a read is in progress in any of your rw-mutex
algos?

Can you read without issuing any memory barriers, or any atomic RMW?

I think NOT!

;^)

[toc] | [prev] | [next] | [standalone]


#2506

FromRamine <ramine@1.1>
Date2014-06-14 12:37 -0700
Message-ID<lni87e$ujb$1@dont-email.me>
In reply to#2505
On 6/14/2014 11:49 AM, Chris M. Thomasson wrote:
>> "aminer"  wrote in message news:lnag6l$hm7$2@news.albasani.net... [...]
>
> IMVHO, you do not seem understand why RCU beats a non-asymmetric
> rw-lock. Besides that, how can you compare RCU with a read-write mutex
> when RCU allows reads and writes to occur concurrently?
>
> Can a write proceed when a read is in progress in any of your rw-mutex
> algos?
>
> Can you read without issuing any memory barriers, or any atomic RMW?
>
> I think NOT!
>
> ;^)

"Read-copy update creates new version at each modification, permitting 
an excellent scalability as concurrent reads scale perfectly and there 
are *NO WRITES* to the same memory location."

Have you read the "and there are no writes to the same memory location"

Also i was spezking about read mostly scenarios, i think
on read mostly scenarios the difference between RCU and my scalable
RWLocks are small, cause my scalable RWLocks are scalable on read mostly 
scenarios , they scale even at 3% of writes.



Thank you,
Amine Moulay Ramdane.





[toc] | [prev] | [next] | [standalone]


#2507

FromRamine <ramine@1.1>
Date2014-06-14 12:49 -0700
Message-ID<lni8t7$403$1@dont-email.me>
In reply to#2505
On 6/14/2014 11:49 AM, Chris M. Thomasson wrote:
> IMVHO, you do not seem understand why RCU beats a non-asymmetric
> rw-lock. Besides that, how can you compare RCU with a read-write mutex
> when RCU allows reads and writes to occur concurrently?
>
> Can a write proceed when a read is in progress in any of your rw-mutex
> algos?


This is not general, when writes and reads happen to the same
memory locations(that's the same for harddisk)  RCU can not run writes 
and reads in parallel.


Also i was speaking about read mostly scenarios, i think
on read mostly scenarios the difference between RCU and my scalable
RWLocks are small, cause my scalable RWLocks are scalable on read mostly 
scenarios , they scale even at 3% of writes.


Thank you,
Amine Moulay Ramdane.

[toc] | [prev] | [standalone]


Back to top | Article view | comp.programming.threads


csiph-web