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

Groups > comp.programming.threads > #4009

Read this about the LMAX Disruptor

Show all headers | View raw

Hello..


Read this about the LMAX Disruptor, it is not a general purpose 
mechanism,  it is not suited for all applications.

"You can see this in the way that producers add values to the ring: they 
first reserve a slot, then later publish it. If there are two 
publishers, and one pauses in the middle (e.g. because the operating 
system or virtual machine does a context switch), it stalls all 
consumers. A second example is that if you want to distribute work 
across a pool of threads, the Disruptor can't help. The FAQ suggests 
distributing work modulo the number of workers, but what happens when 
one work unit is much more expensive than others for some reason? It 
ends up stalling all the future work assigned to that task. 
ArrayBlockingQueue, which they clobber in their benchmarks, is much more 
forgiving.

My point is that even though their ring buffer is very well designed and 
tuned for high performance, it isn't an appropriate choice for all 
applications. However, if you have producer/consumer queues in your 
code, you probably should look to see if Disruptors will match your 
needs, and anyone interested in high performance code should read their 
paper and/or blog posts."

Read more here:

http://www.evanjones.ca/lmax-disruptor.html


This is why i have come with my scalable C++ FIFO queues here:

https://sites.google.com/site/aminer68/scalable-fifo-queues-for-c


And I am actually finishing implemeting my new inventions that are a 
scalable Waifree FIFO queue and a scalable Lockfree FIFO queue.


Please stay tuned !

Thank you,
Amine Moulay Ramdane.

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

Thread

Read this about the LMAX Disruptor Intelli2 <intelli2@mama.com> - 2018-01-02 14:07 -0500

csiph-web