| comp.programming.threads@googlegroups.com | Google Groups |  |
| Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.programming.threads+unsubscribe@googlegroups.com. |
- Stay tuned a new algorithm is coming - 1 Update
- More about my scalable distributed sequential lock - 1 Update
- About RCU and my scalable distributed sequential lock - 1 Update
- About my new algorithm - 2 Updates
| Ramine <ramine@1.1>: Dec 05 08:39PM -0800 Hello, Stay tuned, a new algorithm of mine is coming, it will be called Scalable distributed seuential lock, but this one will be competitive with RCU cause it will be costless on the reader side on read-mostly scenarios, and it will improve on Seqlock cause it will not starve and it will not livelock with more and more writers. Stay tuned my new algorithm is coming soon... Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Dec 05 08:13PM -0800 Hello, We must be smart my dear programmers and hardware engineers... As you have noticed i have invented and implemented a powerful synchronization mechanism called Scalable distributed sequential lock, but we have to be smart please, if you look at the Pthread reader-writer lock , it's not using a distributed algorithm, so it's atomicaly incrementing a shared variable and causing cache lines transfers between cores on the reader side, and this act of incrementing atomicaly a shared variable is considered part of the Serial part of the Amdahl's law, so this act of incrementing atomicaly a shared variable on the reader side of the Pthread reader-writer lock will not scale, but in contrast my scalable distributed sequential lock is using an hybrid mechanism that it runs in two modes, in a Seqlock (sequential lock) mode and in a distributed reader-writer lock mode, that means the distributed algorithm that i am using is rendering this atomic increment on the reader side into a scalable parallel part of the Amdahl's law, cause in my distributed algorithm the "lock add" assembler instruction is only executed by a group of threads belonging to the same core , so this part is considered a parallel part , so then it will scale very well, and that's a big improvement over the Pthread reader-writer lock, now if you have noticed Chris M. Thomasson have just answered to me by saying that RCU don't use atomics or memory barriers on the reader side, so this will make it both "faster" and "scalable", but you have to understand that my new algorithm is less faster than RCU but it's scalable on read-mostly scenarios, and you have to understand also that it improves on some characteristics over Seqlock because my new algorithm will not starve and livelock with more writers, so you have to understand that if you want your website to load balance correctly between the users you can not simply use Seqlock, cause Seqlock gives preference to the writers and it can livelock and starve on scenarios with more writers, so this is why my new algorithm comes in hand because it load balance between readers and writers better than Seqlock. Hope you have unerstood what i want to say in this post, so hope you have found my new algorithm called Scalable distributed sequential lock an interesting invention that you have to take into consideration. You can download my scalable distributed sequential lock from: https://sites.google.com/site/aminer68/scalable-distributed-sequential-lock Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Dec 05 06:03PM -0800 Hello, I have just read carefully what have wrote Chris M. Thomasson, and he have just said that RCU have no memory barrier and no atomic in the reader side, so it is costless on the reader side, and he has said since my new algorithm uses atomics and memory barrier on the reader side so it is slower than RCU , but i don't agree with Chriss Thomasson, because what don't understand Chriss Thomasson is that my new algorithm uses an hybrid algorithm of a distributed algorithm and a sequential algorithm, the distributed algorithm makes the atomics very very cheap in term of running time, and the full memory barrier is still there on the reader side, but what you have to understand that even though there is still a full memory barrier on the reader side of my algorithm, this full memory barrier belongs to the parallel part of the Amdahl's law, so it is fully scalable on read-mostly scenarios and the GetCurrentProcessor() functionof my algorithm is also part of the parallel part of the Amdahl's law, so it is fully scalable on read-mostly scenarios, that makes my new algorithm a very well scalable algorithm on read-mostly scenarios on multicores, so this is why i have told you that my new algorithm can replace RCU because it is very well scalable on read mostly scenarios and it beats Seqlock on some charateristics because it avoids "starvation" and it avoids "livelock" on scenarios with more writers. Thank you, Amine Moulay Ramdane. |
| "Chris M. Thomasson" <no@spam.invalid>: Dec 05 11:32AM -0800 > is run only by the group of threads belonging to the same core, cause > RLock() called from the reader side belong to a distributed algorithm, > so it's very very cheap, it is why my new algorithm scales very well. Comparing RCU read-side with anything that uses an atomic rmw and/or memory barrier is just plain foolish. That LOCK ADD destroys performance when compared to RCU's basically zero overhead reads. End of story. I have been working with RCU for a long time now, and know what I am talking about. Trust me. |
| Drazen Kacar <dave@fly.srk.fer.hr>: Dec 05 10:48PM Chris M. Thomasson wrote: > Comparing RCU read-side with anything that uses an atomic rmw and/or > memory barrier is just plain foolish. That LOCK ADD destroys performance > when compared to RCU's basically zero overhead reads. End of story. I don't quite understand the "or" part of your "and/or memory barrier" statement. If there was a different algorithm which used only memory barrier, but not RMW, would that be so much worse than RCU? Another thing I don't quite understand is in Wikipedia's RCU article (at http://en.wikipedia.org/wiki/Read-copy-update, section Simple implementation) The article says: [RCU's] read-side overhead is precisely zero, as smp_read_barrier_depends() is an empty macro on all but DEC Alpha CPUs;[19] such memory barriers are not needed on modern CPUs. I was under the impression that you'd need memory barrier on Alpha because it does more agressive memory access reordering than other processors. But then, if that's correct, that means that modern CPUs (whichever they are) still don't have features that old Alpha CPUs have. And not the other way round. -- .-. .-. Yes, I am an agent of Satan, but my duties are largely (_ \ / _) ceremonial. | | dave@fly.srk.fer.hr |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.programming.threads+unsubscribe@googlegroups.com. |
No comments:
Post a Comment