Trisha's Ramblings

This month's Java Magazine  features an article by yours truly, which is yet another intro to the Disruptor.  It's basically a summary of the stuff I've written in this blog, updated for version 2.7 - so the names of the classes should be up to date and the responsibilities follow the simplified pattern we use now.  If you were looking for an more recent version of my introduction blog posts, this article gives a reasonable overview. This is intended as part one of a series, as it's a basic and high-level view with no code examples.  In fact, it probably could be used to document the C# version as well as the Java version, although I haven't taken a look at that for a while.  Next, I would like to give some more code examples of how you use it - as always, any suggestions welcome.

Martin recently announced version 2.0 of the Disruptor  - basically there have been so many changes since we first open-sourced it that it's time to mark that officially.  His post goes over all the changes, the aim of this article is to attempt to translate my previous blog posts into new-world-speak, since it's going to take a long time to re-write each of them all over again. Now I see the disadvantage of hand-drawing everything. In the old world This is an example of a configuration of the Disruptor (specifically a diamond configuration).  If none of this means anything to you, feel free to go back and refresh yourself on all the (now outdated) Disruptor details . The most obvious changes over the last few weeks have been: Updated naming convention Integrating the producer barrier into the ring buffer Adding the Disruptor wizard into the main code base. The New World Order You'll see the fundamentals are pretty much the same.  It's simpler, because ...

My recent slow-down in posting is because I've been trying to write a post explaining memory barriers and their applicability in the Disruptor . The problem is, no matter how much I read and no matter how many times I ask the ever-patient Martin and Mike questions trying to clarify some point, I just don't intuitively grasp the subject. I guess I don't have the deep background knowledge required to fully understand. So, rather than make an idiot of myself trying to explain something I don't really get, I'm going to try and cover, at an abstract / massive-simplification level, what I do understand in the area.  Martin has written a post  going into memory barriers  in some detail, so hopefully I can get away with skimming the subject. Disclaimer: any errors in the explanation are completely my own, and no reflection on the implementation of the Disruptor or on the LMAX guys who actually do know about this stuff. What's the point? My main aim in this s...

We mention the phrase Mechanical Sympathy quite a lot, in fact it's even Martin's blog title .  It's about understanding how the underlying hardware operates and programming in a way that works with that, not against it. We get a number of comments and questions about the mysterious cache line padding in the RingBuffer , and I referred to it in the last post .  Since this lends itself to pretty pictures, it's the next thing I thought I would tackle. Comp Sci 101 One of the things I love about working at LMAX is all that stuff I learnt at university and in my A Level Computing actually means something.  So often as a developer you can get away with not understanding the CPU, data structures or Big O notation  - I spent 10 years of my career forgetting all that.  But it turns out that if you do know about these things, and you apply that knowledge, you can come up with some very clever, very fast code. So, a refresher for those of us who studied this at sc...

Martin Fowler has written a really good article describing not only the Disruptor , but also how it fits into the architecture at LMAX .  This gives some of the context that has been missing so far, but the most frequently asked question is still "What is the Disruptor?". I'm working up to answering that.  I'm currently on question number two: "Why is it so fast?". These questions do go hand in hand, however, because I can't talk about why it's fast without saying what it does, and I can't talk about what it is without saying why it is that way. So I'm trapped in a circular dependency.  A circular dependency of blogging. To break the dependency, I'm going to answer question one with the simplest answer, and with any luck I'll come back to it in a later post if it still needs explanation: the Disruptor is a way to pass information between threads. As a developer, already my alarm bells are going off because the word "th...

So now I've covered the ring buffer itself, reading from it and writing to it. Logically the next thing to do is to wire everything up together. I talked about multiple producers - they have the producer barrier to keep them in order and under control.  I've talked about consumers in a simple situation.  Multiple consumers can get a little more involved.   We've done some clever stuff to allow the consumers to be dependent on each other and the ring buffer.  Like a lot of applications, we have a pipeline of things that need to happen before we can actually get on with the business logic - for example, we need to make sure the messages have been journalled to disk before we can do anything. The Disruptor paper and the performance tests cover some basic configurations that you might want. I'm going to go over the most interesting one, mostly because I needed the practice with the graphics tablet. Diamond configuration DiamondPath1P3CPerfTest illustrates ...

This is the missing piece in the end-to-end view of the Disruptor.  Brace yourselves, it's quite long.  But I decided to keep it in a single blog so you could have the context in one place. The important areas are: not wrapping the ring; informing the consumers; batching for producers; and how multiple producers work. ProducerBarriers The Disruptor code has interfaces and helper classes for the Consumer s, but there's no interface for your producer, the thing that writes to the ring buffer.  That's because nothing else needs to access your producer, only you need to know about it.  However, like the consuming side, a ProducerBarrier is created by the ring buffer and your producer will use this to write to it. Writing to the ring buffer involves a two-phase commit.  First, your producer has to claim the next slot on the buffer.  Then, when the producer has finished writing to the slot, it will call commit on the ProducerBarrier . So let's look at...