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


Groups > comp.programming.threads > #2759 > unrolled thread

More about scalability

Started byRamine <ramine@1.1>
First post2014-12-07 16:38 -0800
Last post2014-12-07 17:10 -0800
Articles 2 — 1 participant

Back to article view | Back to comp.programming.threads


Contents

  More about scalability Ramine <ramine@1.1> - 2014-12-07 16:38 -0800
    Re: More about scalability Ramine <ramine@1.1> - 2014-12-07 17:10 -0800

#2759 — More about scalability

FromRamine <ramine@1.1>
Date2014-12-07 16:38 -0800
SubjectMore about scalability
Message-ID<m62hae$g4b$2@dont-email.me>
Hello,


What i like about my scalable distributed sequential lock,
is that if for example you want to implement a really fast and
parallel in-memory database or a Parallel Redblack tree and a parallel
AVL tree, the reader section will be much expensive than the
writer section, cause in the writer side you first write
the data outside the writer section and inside the writer
section you just copy your pointer to the datastructure,
but in the reader section you have to read the data
from the memory from inside the reader section , that makes
the reader section more expensive , so from the Amdahl's
law this will make the parallel in-memory database
that uses my scalable distributed sequential lock to
scale very well(on NUMA etc.) or it will make the the parallel Redblack 
tree or parallel AVL tree that use my scalable distributed sequential 
lock to scale very well (on NUMA etc.).


That's very important to know.


Thank you,
Amine Moulay Ramdane,.

[toc] | [next] | [standalone]


#2760

FromRamine <ramine@1.1>
Date2014-12-07 17:10 -0800
Message-ID<m62j71$mph$1@dont-email.me>
In reply to#2759
Hello,


But you have to use this optimization:


Hello,


If you want to implement an in-memory database with
my scalable distributed sequential lock, and you want
to optimize more the writer side, i mean if you want to
eliminate the expensive full memory barrier of the lock on the writer 
side , what can you do about it ? you can use for example a client 
server mechanism , that means the data is put by the producer threads on 
a queue , and the consumer thread will execute alone the
writer section, and this way you can delete the lock from
the writer side, this will make the writer section much much
faster.



Thank you,
Amine Moulay Ramdane.


[toc] | [prev] | [standalone]


Back to top | Article view | comp.programming.threads


csiph-web