Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #2488 > unrolled thread
| Started by | aminer <aminer@toto.net> |
|---|---|
| First post | 2014-06-11 04:54 -0700 |
| Last post | 2014-06-14 12:49 -0700 |
| Articles | 5 — 3 participants |
Back to article view | Back to comp.programming.threads
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
| From | aminer <aminer@toto.net> |
|---|---|
| Date | 2014-06-11 04:54 -0700 |
| Subject | I 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]
| From | aminer <aminer@toto.net> |
|---|---|
| Date | 2014-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]
| From | "Chris M. Thomasson" <no@spam.invalid> |
|---|---|
| Date | 2014-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]
| From | Ramine <ramine@1.1> |
|---|---|
| Date | 2014-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]
| From | Ramine <ramine@1.1> |
|---|---|
| Date | 2014-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