tag:blogger.com,1999:blog-8231772264325864647.post4478805172850287395..comments2024-03-22T19:05:00.088+01:00Comments on Concurrency Freaks: Combining the StampedLock and LongAdder to make a new RW-LockPedro Ramalhetehttp://www.blogger.com/profile/01340437958052998917noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-8231772264325864647.post-83798757294078136662013-09-24T20:47:38.037+02:002013-09-24T20:47:38.037+02:00Hello,
I have wrote this about my distributed pri...Hello,<br /><br />I have wrote this about my distributed priority and non priority LOCK :<br /><br />"So if you have noticed, in fact i am using 2 CASes , so my algorithm is good."<br /><br /><br />You will say that i will in fact use 3 atomic operations , 2 CASes and one <br />inside the waitfree queue, but be smart please, when there is <br />threads waiting and spining , one CAS among the CASes will be very cheap cause the variable will be inside the L2 cache, and the other CAS will be <br />expensive cause the threads must load the variable from the <br />remote caches and this is expensive, so it is as we would <br />have one CAS cause one amongst the second is very cheap,<br />so it will make this a total of 2 CASes if we count the CAS for <br />the waitfree queue.<br /><br />This was my algorithm for a distributed priority and non priority LOCK<br />that is efficient, and i will code it as soon as possible.<br /><br /><br />Thank you,<br />Amine Moulay Ramdane.<br /><br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8231772264325864647.post-58749452684842441762013-09-24T19:10:53.993+02:002013-09-24T19:10:53.993+02:00Hello,
I have come to an interresting subject ab...Hello,<br /><br /><br />I have come to an interresting subject about lockfree queues,<br />if you take a look at those lockfree queues, like in transactional memory, if the data have changed those lockfree queue retries and loop again, but this (lockfree) mechanism generates a lot of cache-coherence traffic, so i will not advice this lockfree mechanism, so how <br />can we do it ? you can take a look at the MCS queue Lock , i <br />think they are doing it like a waitfree linklist that doesn't spin and <br />that reduces a lot the cache-coherence traffic, other than that <br />if your memory manager is not optimal and uses a lockfree mechanism and generates a lot cache-coherence traffic, so you have to use a freelist to lower the cache coherence traffic.<br /><br /><br />So be smart please and think about that.<br /><br /><br />Thank you,<br />Amine Moulay Ramdane. <br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8231772264325864647.post-85740161739504175972013-09-24T19:00:21.414+02:002013-09-24T19:00:21.414+02:00Hello,
Be smart please, to reduce a lot the cache...Hello,<br /><br />Be smart please, to reduce a lot the cache-coherence traffic,<br />you have to choose a queue that reduces a lot the cache-coherence traffic, and for that you have to code a queue as a linklist<br />(similar to to the MCS queue) that reduces a lot the cache-coherence traffic, but you have to avoid the lockfree queues cause they will higher the cache-coherence traffic. This is how you have to code my distributed LOCK and it will efficient and be good.<br /><br /><br /><br />Thank you,<br />Amine Moulay Ramdane. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8231772264325864647.post-48388473711752444622013-09-24T17:49:46.011+02:002013-09-24T17:49:46.011+02:00I correct some typos, please read again...
Hello,...I correct some typos, please read again...<br /><br />Hello,<br /><br />Here is my new algorithm for a distributed priority and<br />non priority LOCK, this algorithm reduce a lot the<br />cache-coherence traffic and is good, so follow me please...<br /><br /><br />First you you allocate an array with the same number of elements<br />as the numbers of cores and the elements in the array must be 64 bytes<br />cache aligned and must be a record containing one element that is the<br />a flag for the first CAS that will be used as a critical section .<br /><br />You first initialise the distributed priority LOCK by setting<br />a flag for the second CAS that will be used as a critical section to 0 and you set the flag of the first CAS that will be used also as a critical section to 1 (to permit the first thread to enter the lock())<br /><br />The lock() function will look like this:<br /><br />Every thread that enters the lock() must acquire his processor<br />number by using GetProcessorNumber() function, but this function<br />will be optimized to amortize the number of calls to it, and that's<br />easy to do.<br /><br />You enter the lock() function by pushing the processor number of the threads into a queue or priority queue that will be optimized, this queue will be using a CAS on the push() and will not use any CAS on the pop(), we don't need it on the pop() cause only one thread will pop() from the unlock() function, after that you enter a repeat loop where you test with the first CAS and you test also with the second CAS the flag of the corresponding element(flag) of the array using the processor number of the threads as an index , the flag for the second CAS will be set to 1 so the first thread will enter the lock() and the other threads will test in a repeat loop for the first CAS and the second CAS and there flags will have been set to zero so they will wait..<br /><br />After that the first thread will arrive to the unlock() function and<br />he will pop() the processor number from the optimized priority queue<br />or non priority queue and set the flag for the first CAS to 1 for the corresponding processor core this will allow a thread to enter the lock , if there is no elements in the queue the thread will set the flag of the second CAS to 1 and this will allow a thread to enter the lock.<br /><br /><br />So as you have noticed my algorithm is efficient also cause if there<br />is threads waiting, the cache-coherence traffic will be reduced a lot<br />cause we are using local variables in each element of the array alligned to 64 byte.<br /><br /><br />So if you have noticed, in fact i am using 2 CASes , so my algorithm<br />is good.<br /><br />This was my algorithm for a distributed priority and non priority LOCK<br />that is efficient, and i will code it as soon as possible.<br /><br /><br /><br />Thank you,<br />Amine Moulay Ramdane.<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8231772264325864647.post-19413602464840669342013-09-24T17:11:19.188+02:002013-09-24T17:11:19.188+02:00Hello Pedro,
Here is my new algorithm for a dis...Hello Pedro, <br /><br /><br />Here is my new algorithm for a distributed priority and<br />non priority LOCK, this algorithm reduce a lot the<br />cache-coherence traffic and is good, so follow me please...<br /><br /><br />First you you allocate an array with the same number of elements<br />as the numbers of cores and the elements in the array must be 64 bytes<br />cache aligned and must be a record containing one element that is the<br />a flag for the first CAS that will be used as a critical section .<br /><br />You first initialise the distributed priority LOCK by setting<br />a flag for the second CAS that will be used as a critical section to 0 and you set the flag of the first CAS that will be used also as a critical section to 1 (to permit the first thread to enter the lock())<br /><br />The lock() function will look like this:<br /><br />Every thread that enters the lock() must acquire his processor<br />number by using GetProcessorNumber() function, but this function<br />will be optimized to amortize the number of calls to it, and that's<br />easy to do.<br /><br />You enter the lock() function by pushing the processor number of the threads into a queue or priority queue that will be optimized, this queue will be using a CAS on the push() and will not use any CAS on the pop(), we don't need it on the pop() cause only one thread will pop() from the unlock() function, after that you enter a repeat loop where you test with the first CAS and you test also with the second CAS the flag of the corresponding element(flag) of the array using the processor number of the threads as an index , the flag for the second CAS will be set to 1 so the first thread will enter the lock() and the other threads will test in a repeat loop for the first CAS and the second CAS and there flags will have been set to zero so they will wait..<br /><br />After that the first thread will arrive to the unlock() function and<br />he will pop() the processor number from the optimized priority queue<br />or non priority queue and set the flag for the first CAS to 0 for the corresponding processor core this will allow a thread to enter the lock , if there is no elements in the queue the thread will set the flag of the second CAS to zero and this will allow a thread to enter the lock.<br /><br /><br />So as you have noticed my algorithm is efficient also cause if there<br />is threads waiting, the cache-coherence traffic will be reduced a lot<br />cause we are using local variables in each element of the array alligned to 64 byte.<br /><br /><br />So if you have noticed, in fact i am using 2 CASes , so my algorithm<br />is good.<br /><br />This was my algorithm for a distributed priority and non priority LOCK<br />that is efficient, and i will code it as soon as possible.<br /><br /><br /><br />Thank you,<br />Amine Moulay Ramdane.<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8231772264325864647.post-89851328542030567992013-09-23T01:19:47.947+02:002013-09-23T01:19:47.947+02:00
Hello Pedro,
I have used my SemaMonitor inside m...<br />Hello Pedro,<br /><br />I have used my SemaMonitor inside my RWLock and benchmarked<br />it against the Windows Semaphore and i have found that it is faster than the Windows Semaphore. You will find my SemaCondvar and <br />my SemaMonitor on the following website:<br /><br />http://pages.videotron.com/aminer/<br /><br /><br />Thank you,<br />Amine Moulay Ramdane.<br /><br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8231772264325864647.post-9858632488515115672013-09-23T01:10:33.948+02:002013-09-23T01:10:33.948+02:00Hello Pedro,
I have updated my RWLock to version ...Hello Pedro,<br /><br />I have updated my RWLock to version 1.1 , i have added another <br />version of my RWLock , please read the following description:<br /><br />Description:<br /><br />A fast, and scalable, and lightweight Multiple-Readers-Exclusive-Writer Lock that is portable called LW_RWLock and that works across processes and threads and a fast and scalable Multiple-Readers-Exclusive-Writer Lock called RWLock that is portable and that don't use spin wait but uses an event object and also my SemaMonitor and that consumes less CPU than the lightweight version and it processes now the writers on a FIFO order and that's also important and it works across threads .<br /><br />You can take a look at it on the following website:<br /><br />http://pages.videotron.com/aminer/<br /><br /><br />Thank you,<br />Amine Moulay Ramdane.<br />Anonymousnoreply@blogger.com