Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #2759 > unrolled thread
| Started by | Ramine <ramine@1.1> |
|---|---|
| First post | 2014-12-07 16:38 -0800 |
| Last post | 2014-12-07 17:10 -0800 |
| Articles | 2 — 1 participant |
Back to article view | Back to comp.programming.threads
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
| From | Ramine <ramine@1.1> |
|---|---|
| Date | 2014-12-07 16:38 -0800 |
| Subject | More 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]
| From | Ramine <ramine@1.1> |
|---|---|
| Date | 2014-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