Disruptor framework example at Oracle

[Rajiv Kurian]

I just saw this talk on youtube : http://www.youtube.com/watch?v=eTeWxZvlCZ8

It explains the disruptor pattern with the example of a car assembly line. There are multiple event processors reading from a ring buffer and modifying the objects in the ring buffer.  A single producer produces a car object with only the chassis field set. The first three event processors read this event and modify the car object on the ring buffer to set the rear seats, front seats and an engine fields. Since they are reading the object in parallel and writing to it too, won't there be contention?

The talk mentions that each of these event processors will write a different field and so there won't be that much contention. Event though the event processors are writing different fields won't there be false sharing since these fields are probably laid next to each other on the cache line?  It seems like whenever multiple event processor are trying to write to an event in the ring buffer in parallel, there will be significant contention. Am I missing something?

Thanks,
Rajiv

[Trisha Gee]

Hi Rajiv.

The aim of this talk was to get people thinking about how to parallelise their problems, and understand what could be parallelised and what were the real dependencies (hence the car assembly line analogy).

It demonstrated a particular way to use the Disruptor, where the Events were modified in the RingBuffer to allow different threads to process the event and annotate it with results.  It's a pattern that was tried at LMAX in the early days, but is not used now as there's no performance benefits and it's a bit tricky to reason around, for exactly some of the reasons you point out - the fields might be subject to false sharing for example.

I wrote that talk a couple of years ago, and things have moved on a bit since then - both in terms of the Disruptor framework itself (the API for example) and in terms of the best use-cases for it. The information is still valid, but the main take away point should be understanding how to identify your event processors - what should be parallel and what should be sequential.

Trisha

--
You received this message because you are subscribed to the Google Groups "Disruptor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lmax-disrupto...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Nitsan Wakart]

"...and things have moved on a bit since then - both in terms of the Disruptor framework itself (the API for example) and in terms of the best use-cases for it."

I realize this is perhaps a lot to ask, but could you give a brief analysis or point at such an analysis? I'm more interested in how the use-cases changed rather than the API, but one reflects the other I suppose.

---

From: Trisha Gee <trish...@gmail.com>
To: lmax-di...@googlegroups.com
Sent: Friday, May 10, 2013 9:02 AM
Subject: Re: Disruptor framework example at Oracle

[Trisha Gee]

I'm not sure it's that easy to give an overview of the use cases (although that would be awesome actually).  I'm personally going on the history of this mailing list, where we've seen people explaining their own different uses of the Disruptor.  I can't speak for LMAX any more since I'm not working there any more, maybe others on this list could give a quick summary of how they're using the Disruptor in anger?

Trisha

[Nitsan Wakart]

:)

It is that awesome overview I was hoping you had hidden in your drawer... It would be good if LMAX gave a short history of their use-case which was the driving force and is also the most documented. I would be interested in your list of points off the top of your head if you feel comfortable sharing it.

---

From: Trisha Gee <trish...@gmail.com>
To: lmax-di...@googlegroups.com

Sent: Friday, May 10, 2013 9:17 AM

[Martin Thompson]

If you need to have multiple threads working on the same entity, e.g. Car, then you should not work on the same actual object because of false sharing as you point out.  A much better way to do this is to use the Sequencer directly and then create an array for each field in the entity being represented.  The sequence to be processed can be indexed into the array using a reminder operation with the size of the array.

By taking this approach not only do you avoid the contention, you have each thread walking through memory sequential which works well with the hardware pre-fetchers, plus you save the object header and in-direction costs of real objects.  If you need to materialise a cohesive object then simply map a flyweight pattern over the list of arrays for a given index.

Martin...