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

Groups > comp.programming.threads > #2309

More information...

Cross-posted to 2 groups.

Show all headers | View raw

vfclists wrote:
 >Hi,
 >I have noticed your regular updates about your fair lock and other 
 >concurrency related issues and would like to know what kind of areas 
 >they are >applicable to. Can you give me an idea of >what I might need 
 >something like that for?

 >Seeing these topics make me feel my Computer Science knowledge is 
 >inadequate.

Jurassic Pork wrote:
 >hello Aminer,
 >have you seen  :o the vfclists 's question ? i have the same


Read here:

http://forum.lazarus.freepascal.org/index.php/topic,24210.30.html


And my answer:

I have wrote:

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

For exemple 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 
transfer from one cor to the other, and this a cache-line transfer is 
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."


I will also add something important:

If you look at my very fast concurrent FIFO queue here:

http://pages.videotron.com/aminer/CQueue3.htm



As you have noticed i am not using a lock around the push()
and another lock around the pop(), and you have to understand
that for example the "setObject(lastHead,tm)" will be executed
in parallel and each thread will write the tm variable
in its write-back cache , that means it will not write immedialy
the content of the variable to the memory , but will write it latter,
so this parallelism will higher the throughput and this is what i have 
noticed on my benchmarks , i have got more throughput than the two-lock 
algorithm, but when you are using a lock around the push()
and a lock around the pop() you will not get this parallelism
so this will drop the throughput... and that's the same for
the pop() method , the "if fcount1^[lastTail and fMask].flag=1"
can be executed in parallel and the inter-communication between
the cores can be done in parallel so this will higher the throughput...
This is  why i have told you that my new algorithm of a very fast 
concurrent FIFO queue has more parallelism than the two-lock algorithm , 
and it has a much better throughput, and it will scale better with more 
and mor cores.


Please take a look at my other projects here:

http://pages.videotron.com/aminer/



Thank you,
Amine Moulay Ramdane.

Back to comp.programming.threads | Previous | Next | Find similar | Unroll thread

Thread

More information... aminer <aminer@toto.net> - 2014-05-06 22:12 -0700

csiph-web