Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Wisdom90 Newsgroups: comp.programming.threads Subject: Re: Read again my "final" corrected post about about efficiency and performance.. Date: Wed, 16 Oct 2019 14:19:33 -0400 Organization: A noiseless patient Spider Lines: 78 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 16 Oct 2019 18:19:33 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="23237738623bf2ac373deed43b632389"; logging-data="30106"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19rT8WpNPk+EUERvU+Xokni" User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 Cancel-Lock: sha1:YR5GiEyDHrdGr7wX4hX5tgQQWSE= In-Reply-To: Content-Language: en-US Xref: csiph.com comp.programming.threads:5250 On 10/16/2019 2:14 PM, Bonita Montero wrote: >> I think i am also smart, so i have just quickly found a solution that >> is scalable and that is not your solution, so it needs my hashtable >> that scales very ... > > A scaling hashtable is easy. > >> ... scales very well and it needs my fully scalable FIFO queue that >> i have invented. > > That's also easy. > >> But i will not patent it, .. > > There's prior art for both. > As someone else told you: your ideas aren't new. > >> because i will let you patent yours since i have seen you speaking on >> the newsgroup of C++ about it. > > I'd have no problem if you show my idea as prior art. > So go on. > >> But my solution is not Lockfree, it uses locks and it is scalable. > > A locking LRU-list is never scalable. On 10/16/2019 1:33 PM, Wisdom90 wrote: > Hello... > > > About the LRU scalable algorithm.. > > On 10/16/2019 7:48 AM, Bonita Montero on comp.programming.threads wrote: > > Amine, a quest for you: > > Database-servers and operating-system-kernels mostly use LRU as > > the scheme to evict old buffers from their cache. One issue with > > LRU is, that an LRU-structure can't be updated by multiple threads > > simultaneously. So you have to have a global lock. > > I managed to write a LRU-caching-class that can update the links > > in the LRU-list to put the most recent fetched block to the head > > of the list without any lock in almost any acccess. Only when > > flushing an entry or inserting a new I have to lock the structure > > completely; but in contrast to cache-hits this has usually a mag- > > nitude lower frequency because of the slowness of disk-/ssd-access, > > so this doesn't relly hurt. > > The algorithm is partitiylly locked, partitially lock-free. Even > > the case when putting cache hits to the head has to be processed > > in locked mode in very rare cases. And as I said inserting and > > flushing is conventional locked access. > > So the quest is for you: Can you guess what I did? > > > > I think i am also smart, so i have just quickly found a solution that is > scalable and that is not your solution, so it needs my hashtable that > scales very well and it needs my fully scalable FIFO queue that i have > invented. But i will not patent it, because i will let you patent yours > since i have seen you speaking on the newsgroup of C++ about it. > > > But my solution is not Lockfree, it uses locks and it is scalable. > > > Thank you, > Amine Moulay Ramdane. > A locking LRU-list is never scalable. I said it uses locks and it is scalable, because locks are distributed like when you does lock striping. So there is no logical contradiction in my writing. Thank you, Amine Moulay Ramdane.