| 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. |
- About my scalable RWLocks and Seqlock - 2 Updates
- About my scalable RWLocks - 2 Updates
- About Parallel Hahslist - 1 Update
| Ramine <ramine@1.1>: Nov 25 02:27PM -0800 Hello, This time i will speak about my scalable RWLocks and i will compare them to the Seqlock. What i don't like in Seqlock , is that it doesn't treat correctly the general cases of scenarios that we can have, i mean let say that we are in a case scenario that is not read mostly and we have many more writes and we don't want to have starvation and we don't want to have livelock , Seqlock is not suitable for this case scenaio cause it can livelock and it can have starvation.. this is why i have invented my scalable RWLocks that contain scalable RWLock variants that are starvation-free and livelock-free and that are suitable for the general scenarios of the read mostly scenario or with the scenarios of many more writes, other than that if you look at the source code of my scalable RWLocks , you will notice that i am using something like this: --- for i:=0 to GetSystemThreadCount-1 do begin while (FCount1^[i].fcount1<>0) do begin end; end; --- This part is not only a serial part in the Amdahl law cause in a case scenario with more contention, as soon as we transfer some of all the cache-lines from the array "FCount1^[i].fcount1", the reader threads will still be able to run the reader section in parallel with the transfering of those cache-lines from the writer side, so this part above will run in parallel with many reader threads that will run the reader section, so that makes my scalable RWLocks more scalable. You can download my scalable RWLocks from: https://sites.google.com/site/aminer68/scalable-rwlock Thank you, Amien Moulay Ramdane. |
| Ramine <ramine@1.1>: Nov 25 03:44PM -0800 On 11/25/2014 2:27 PM, Ramine wrote: > correctly the general cases of scenarios that we can have, > i mean let say that we are in a case scenario that is not > read mostly and we have many more writes and we don't want I mean: with many more writers... |
| Ramine <ramine@1.1>: Nov 25 02:52PM -0800 Hello, So as you have noticed i have invented my scalable RWLocks that contain also scalable RWLocks's variants that are starvation-free and livelock-free.. the Seqlock doesn't fullfil this requirement for the scenarios that contain many more writes... so i think i will not port the Seqlock that was wrote in Java to Delphi and Freepascal, cause i feel that my scalable RWLocks are really good and scalable on read mostly scenarios and they are starvation-free and livelock-free even on scenario with many more writers , so i think that my scalable RWLocks can replace even RCU cause they are really scalable on read-mostly scenarios, and my scalable RWLocks can replace Seqlock cause Seqlock can livelock and can starve on scenario with many more writers... So i will advice you to use my scalable RWLocks cause they are really good: https://sites.google.com/site/aminer68/scalable-rwlock Thank you, Amine Moulay Ramdane. |
| "Chris M. Thomasson" <no@spam.invalid>: Nov 25 03:20PM -0800 > really scalable on read-mostly scenarios, and my scalable > RWLocks can replace Seqlock cause Seqlock can livelock and > can starve on scenario with many more writers... FWIW, Seqlocks were simply NOT designed with a lot of writers in mind. A lot of writers wrt RCU doesn't really cast terrible effects on the read-side performance. Therefore, I do not really understand your point for a Seqlock is not meant for a lot of writers! If you came up with a rwlock that can beat RCU read side, well, then you may have something neat here. Have you tested against a well engineered RCU implementation? FWIW, I cannot beat RCU with any traditional rwlock. A possible exception to this would be Dmitry Vyukov's EXCELLENT asymmetric rwlock. However, this would hardly be traditional! ;^D AFAICT, the key is in the clever asymmetry between readers and writers... |
| Ramine <ramine@1.1>: Nov 25 06:25AM -0800 Hello, As you know i have implemented a Parallel Hashlist (a parallel hashtable) that uses fine-grained locking using lock-striping, but i have just corrected a bug in the Find() method of Parallel Hahslist, and i have modified a little bit the interface of the Find() method, please look inside the "test.pas" example to see how to use it.. i have thought more to how to avoid modifying the interface of the Find() method, and i have come to the conclusion that i have to derive from TPersistant the object that you pass to the Remove() and Add() and Find() methods , so when i am inside the scalable RWLock inside the Find() method i have to return a copy of the Object that is derived from TPersistent, but i have thought more about this, and i have come to the conclusion that this method of deriving from TPersistent and returning a copy of the object from the Find() method is subject to a bug in parallel programming if the object contains a reference ( a pointer) to another object and that this reference can be freed when returning from the Remove() method, so because of this constraint i have decided to keep the new modified interface. My Parallel Varfiler don't have this bug/problem. You can download the new version of my Parallel Hahslist from: https://sites.google.com/site/aminer68/ I have also corrected a memory leak inside my Parallel Varfiler, you can download the new version from: https://sites.google.com/site/aminer68/ Thank you, Amine Moulay Ramdane. |
| 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