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

Groups > comp.programming.threads > #2430

I have looked at the following Omnithread library...

Cross-posted to 2 groups.

Show all headers | View raw

Hello,


I have looked at the following Omnithread library...

http://otl.17slon.com/


And this Omnithread library doesn't scale cause it is
using a lockfree FIFO queue.

And i have thought more about lockfree algorithms..

I think that lockfree algorithm are very very bad..

I have told you before that i have benchmarked the following
concurrent FIFO queues that uses lockfree machanism..

This one:

http://code.google.com/p/omnithreadlibrary/downloads/detail?name=OmniThreadLibrary-3.03b.zip&can=2&q=

This one:

http://www.odsrv.com/RingBuffer/RingBuffer.htm


And what i have told you is that they are 2x times slower than
my new algorithm that is not lockfree, here is my new algorithm:

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


But that's not the complete picture, cause what i have done is
testing those lockfree algorithms under contention with only 4 cores,
but as soon as you will use more and more cores the throughput of those
lockfree algorithms will drop more and more and this is not
acceptable.. but why the throughtput of lockfree algorithms will drop 
more and more with more and more cores ? cause lockfree algorithms don't 
minimize efficiently the cache-coherence traffic as is doing my new 
algorithm above, so under contention and with more and more cores the 
lockfree mechanism of those lockfree algorithms causes more and more 
contention because the threads that fail will slow more and more the 
next thread that will succeed because of high cache-coherence traffic 
and  high contention on the bus ... and this is not acceptable !, so i 
think that lockfree algorithms are complete crap
that must be avoided ! other than that lockfree algorithms are not 
starvation-free.


So i advise you you to use my new concurrent FIFO queue algorithm
that is very fast, my new algorithm satisfies many requirements: it has 
more parallelism than the two locks algorithm, it is FIFO fair , it's 
starvation-free and it minimizes efficiently the cache-coherence traffic 
and it is energy efficient on the pop() side when you set the wait 
parameter to true in the construtor: when there is no items in the queue 
it will not spin-wait , but it will block wait on my SemaMonitor, and 
when the wait parameter of the constructor is set to false it uses only 
an atomic increment on the push() side and an atomic increment on the 
pop() side, so it's very fast. The number of threads on the push() side 
are limited by the length of the queue, and the number of threads on the 
pop() side are limited by the length of the queue, the length of the 
queue must be greater or equal to 2^10, i have set it like that.



You can download my new concurrent FIFO queue from:

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




Thank you,
Amine Moulay Ramdane.

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

Thread

I have looked at the following Omnithread library... aminer <aminer@toto.net> - 2014-06-07 08:42 -0700

csiph-web