Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #2761
| From | Ramine <ramine@1.1> |
|---|---|
| Newsgroups | comp.programming.threads |
| Subject | An Architect way of thinking on parallel programming |
| Date | 2014-12-07 17:26 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <m62k4k$r83$2@dont-email.me> (permalink) |
Hello, This time since i have mastered to a certain level the reader-writer algorithms, i will this time think as an architect on parallel programming to show you something important, here it is: As you have seen me talking on my previous post, i have said that with the client-server mechanism that i have given you before , we can eliminate the lock synchronization mechanism from the writer side, and we can make the writer side very very cheap in term of running time compared to the reader section, so there is a very important question that we can ask then, does transactional memory, hardware or sofotware, will buy you much when designing a client-server parallel in-memory database or an client server parallel AVL tree or a client server parallel Red black tree ? i think it will not buy you much in term of runnning time, because with the client-server technic that i have given you above and that eliminates the lock synchronization from the writer side of the reader-writer algorithm , this will make the writer side very cheap in term of running time compared to the reader section that will be expensive in this scenario, because as i have said before is this: 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.). Hope you have understood my way of thinking like as an architect on parallel programming... Thank you, Amine Moulay Ramdane.
Back to comp.programming.threads | Previous | Next | Find similar | Unroll thread
An Architect way of thinking on parallel programming Ramine <ramine@1.1> - 2014-12-07 17:26 -0800
csiph-web