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

Groups > comp.programming.threads > #5250

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

Show key headers only | View raw

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.

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