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

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

The concurrency area is very interresting

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

Contents

  The concurrency area is very interresting aminer <aminer@toto.net> - 2014-06-07 09:37 -0700

#2431 — The concurrency area is very interresting

Hello,


The concurrency area is very interresting, i will explain to you more 
some concepts so that you  understand my scalable synchronization 
algorithms that i have invented..

For example when a mutating integer variable (a variable that change) is 
used  from multiple threads, the content of this variable have to be 
transfered from one core to another core, and this generate cache-line 
transfers from one core to the other, and this a cache-line transfers 
are expensive, so you have to optimize more your algorithm to reduce the 
number of variables that generate cache-line transfers cause those 
variables will generate more contention and will slow your algorithm, 
and if you are spin-waiting waiting for a specific content of a variable 
that is mutating you have to minimize efficienly the cache-coherence 
traffic, that means you have to do your best to transform your algorithm 
so that this spin-waiting on a specific content of a variable will 
generate less cache-line transfers, this is what is doing my algorithms, 
my algorithms of my scalable sychronization algorithms and my algorithms 
of  efficient concurrent FIFO queues are efficient in the sense that 
they reduce the cache coherence traffic and they use less variables that 
generate cache-line transfers.

My scalable array based Lock called AMLock is a scalable Lock, scalable 
in the sense that with more and more cores its throughput will not drop..

My scalable node based Lock called MLock is also scalable Lock, scalable 
in the sense that with more and more cores its throughput will not drop..

My scalable RWLocks are scalable and fast 
Multiple-Readers-Exclusive-Writer Locks that works across processes and 
threads, scalable means that the reader side scales cause it doesn't use 
expensice atomic operations on the reader side as is doing the 
non-scalable MREW of the Omnithread library , and the readers will be 
run in parallel , so you will get more performance by parallelizing the 
reader side, and the reader side is scalable and efficient.

My new algorithm of a very fast concurrent FIFO queue here:

https://sites.google.com/site/aminer68/concurrent-fifo-queue-1

It is a concurrent FIFO queue that uses less variables that generate 
cache-line transfers and it minimizes the cache-coherence traffic so 
that it scales better with more and more cores.

Please take a look at my other projects here:

https://sites.google.com/site/aminer68/



Thank you,
Amine Moulay Ramdane.

[toc] | [standalone]

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

csiph-web