I’ve produced a very cut down version of the presentation I’ve been giving at a lot of conferences, giving a high level overview to the Disruptor. This serves as a quick intro to the concepts behind it. Introduction to the Disruptor from Trisha Gee My slides are usually pretty useless without me (or someone else) talking over them, so for more context don’t forget there’s always my original blog posts (the Magic Ring Buffer, Reading from it, Writing to it, Wiring it up), which are now pretty dated, and the Java Magazine article I wrote at the start of the year.
On Sunday I gave my very first workshop on the Disruptor. The aim was to give people some hands-on coding experience using the syntax. Because time was limited (you can’t get people to build an entire application architecture in 2.5 hours) the example is somewhat contrived, and needs a big leap to make it into a proper application context. But the workshop should:Give an overview of the DisruptorShow how to create a simple one producer, one consumer example.Show how to wire up a parallel event handlerShow how to how (and why) to create a diamond dependency graph.Extrapolate beyond these very simple examples to something closer to a real world architecture.Requirements are:Basic Java skillsJava 7 update 7(Optionally) IntelliJ.The slides (not all that useful, I’ll grant you, without me talking) are available, and you can download the code.If you want to work through the examples yourself, start with com.mechanitis.towerdefense.TowerDefence.
The “User’s Guide to the Disruptor” presentation I gave at QCon London is now available on the InfoQ site. This is the same presentation as the one I gave at Skillsmatter in March, but the questions are different. Plus since I’m winging it every time, I probably cover slightly different things or explain some stuff better / worse.
I was flattered to be interviewed for InfoQ at QCon London. It was a fun interview actually, and didn’t feel anything like the half an hour it actually took. In it, I get to talk about Agile at LMAX, the Disruptor (of course) and diversity in IT (again).
Here’s a video of my Open Conference session on the business benefits of open sourcing your software. Given that the conference was at a weekend and had a very intimate feel, I think I was a teeny bit more honest than I usually am. Enjoy. Why Open Source Your Secrets View more presentations from Trisha Gee.
I’m late with my write-up of QCon, and what’s worse, it will be partial - “sadly” I was in Lanzarote on a training week with the running club from the Thursday (8th) so I missed most of it. A sacrifice I had to make for 7 days in the sunshine….Firstly, me me meI presented the talk I previewed at Skillsmatter the previous week, something I was calling the User’s Guide to the Disruptor, but actually turned out to be how-can-Trish-fill-95-slides-with-pictures-and-finish-in-under-40-minutes.The audience was different to the Skillsmatter event, not surprisingly. What was surprising is that I expected people at the conference to be less aware of the Disruptor, and those who came to the Disruptor-only LJC event to have had more exposure to it. It was a (pleasant) surprise to see how many of the standing-room-only audience had not only heard of the Disruptor but had read stuff about it (I always love it when people have read my blog), played with it and were even using it in anger.Because of that, I think if anything the talk did not go into enough detail, or enough new stuff, to please everyone. Tough crowd! But it was gratifying to hear the audience correct me in some of my answers, and answer other people’s questions - it’s always nice to know people are listening.Of course, I will post a link to the presentation when it’s available.
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.
A few weeks ago, I presented my new “User’s Guide to the Disruptor” talk to the London Java Community. Since it was very kindly hosted at Skillsmatter, there is a video of the presentation available, and the slides are below. Concurrent Programming Using the Disruptor View more presentations from Trisha Gee The presentation is a little different to the ones we’ve done before. Previously we’ve gone into how it works and why it’s fast.
In theory, I am busy writing material for my upcoming speaking events, rather than writing terribly illuminating posts on my blog (see what I did there?). In actuality I am being lazy and have pretty much taken January off for a recharge.In the spirit of doing something which ticks both the event-speaking and blogging boxes, this is a quick update on the conferences I’m confirmed for so far. Put the following dates in your diary - these are my first international solo speaking events:7th March - QCon London - Concurrent Programming Using The Disruptor (sadly I can’t stay for the whole conference as it clashes with the only holiday I had booked for 2012).23rd May - GOTO Copenhagen - Concurrent Programming Using The Disruptor & War Stories.25-26th May - GOTO Amsterdam - Concurrent Programming Using The Disruptor.The presentation will be more of a user’s guide to the Disruptor than anything we’ve done before.
At JAX London Mike and I presented “Understanding the Disruptor - A Beginner’s Guide to Hardcore Concurrency”. This is the session we initially previewed to the London Java Community a few weeks earlier. The content is the same, but the feel of the presentation was quite different to us - the venue for the LJC event was more intimate, and it was easier to interact with the audience. At JAX, we were up on stage, which was pretty cool actually, but meant that it felt more like a lecture and it was less easy to connect with the audience.
Saturday was, hopefully, my last conference of the year. My lucky readers should start to see some posts which are not simply me gushing about another opportunity to hang out with awesome people and learn about interesting “stuff”.Who wants to propose a session?In many ways the London Java Community Open Conference was my favourite one so far, and not just because it’s near home and I helped to organise it. One of the awesome things about both Java One and Devoxx was the opportunity to travel, to see new places and to meet people you might not meet in London.
Last Tuesday Mike and I unveiled our brand shiny new presentation: Understanding the Disruptor, a Beginner’s Guide to Hardcore Concurrency. This was a preview of the talk we’ll be doing at JAX London on the 2nd November.A video of the session is available, as are the slides. I promise not to say “so” anywhere near as many times when I repeat my performance at JAX (is there anything more painful than watching yourself on video?).I thought the session went really really well.
Having been back in London for a few days I’ve had some time to digest the madness that was last week.My lasting impression of JavaOne is almost entirely positive. Granted, it was my first major conference, so maybe I’m just not jaded yet. But let me tell you what I loved about it (yes, I did cover some of these in my last post):First and foremost, the people. I don’t remember meeting a single grumpy person.
So I’ve been at JavaOne for the better part of three days, it’s time to record some of my observations so far:The wireless access is rubbish.<Gross generalisation> technical people are not natural public speakers. Makes me feel better about the presentations I’m going to be giving (see A Beginner’s Guide to Hardcore Concurrency).The sessions are less useful than getting out and chatting. I’ve had a really excellent time, I’ve met: people from other Java User Groups; the Duchess girls; other Duke Award winners; the Azul guys; guys (well, girls) from O’Reilly books; JCP members and many random and awesome people.Everyone thinks that Large is an acceptable default t-shirt size (it’s not).
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 worldThis is an example of a configuration of the Disruptor (specifically a diamond configuration).
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.
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 101One 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.
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.
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.
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.ProducerBarriersThe Disruptor code has interfaces and helper classes for the Consumers, but there's no interface for your producer, the thing that writes to the ring buffer.
The next in the series of understanding the Disruptor pattern developed at LMAX.After the last post we all understand ring buffers and how awesome they are. Unfortunately for you, I have not said anything about how to actually populate them or read from them when you’re using the Disruptor.ConsumerBarriers and ConsumersI’m going to approach this slightly backwards, because it’s probably easier to understand in the long run. Assuming that some magic has populated it: how do you read something from the ring buffer?
Recently we open sourced the LMAX Disruptor, the key to what makes our exchange so fast. Why did we open source it? Well, we’ve realised that conventional wisdom around high performance programming is… a bit wrong. We’ve come up with a better, faster way to share data between threads, and it would be selfish not to share it with the world. Plus it makes us look dead clever.On the site you can download a technical article explaining what the Disruptor is and why it’s so clever and fast.