Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming.threads > #5248

Re: Read again my "final" corrected post about about efficiency and performance..

Path csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From Wisdom90 <d@d.d>
Newsgroups comp.programming.threads
Subject Re: Read again my "final" corrected post about about efficiency and performance..
Date Wed, 16 Oct 2019 13:29:34 -0400
Organization A noiseless patient Spider
Lines 33
Message-ID <qo7k1u$9cn$1@dont-email.me> (permalink)
References <a56ddc60-5f15-4dd4-b415-d4932b2313f9@googlegroups.com> <qo702n$63k$1@news.albasani.net>
Mime-Version 1.0
Content-Type text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding 7bit
Injection-Date Wed, 16 Oct 2019 17:29:34 -0000 (UTC)
Injection-Info reader02.eternal-september.org; posting-host="23237738623bf2ac373deed43b632389"; logging-data="9623"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19coTw0UZpHsatJkinZVa3Y"
User-Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2
Cancel-Lock sha1:hXIp25Pg21zRplamdjgW/d+Op1I=
In-Reply-To <qo702n$63k$1@news.albasani.net>
Content-Language en-US
Xref csiph.com comp.programming.threads:5248

Show key headers only | View raw


On 10/16/2019 7:48 AM, Bonita Montero 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.

Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Read again my "final" corrected post about about efficiency and performance.. aminer68@gmail.com - 2019-10-14 14:18 -0700
  Re: Read again my "final" corrected post about about efficiency and performance.. Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-16 13:48 +0200
    Re: Read again my "final" corrected post about about efficiency and performance.. Wisdom90 <d@d.d> - 2019-10-16 13:29 -0400
      Re: Read again my "final" corrected post about about efficiency and performance.. Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-16 20:14 +0200
        Re: Read again my "final" corrected post about about efficiency and performance.. Wisdom90 <d@d.d> - 2019-10-16 14:19 -0400
          Re: Read again my "final" corrected post about about efficiency and performance.. Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-17 05:07 +0200
        Re: Read again my "final" corrected post about about efficiency and performance.. Wisdom90 <d@d.d> - 2019-10-16 14:20 -0400

csiph-web