Skip to content


Subversion checkout URL

You can clone with
Download ZIP
The LMAX Disruptor in Ruby.
Branch: master


latest commit fed08d6d65
@ileitch authored
Failed to load latest commit information.
bm Add Rubocop.
lib beta4
spec Implement Queue#size.
.gitignore Ignore pkg/
.rspec Fix specs.
.rubocop.yml Add gemspec.
.ruby-version House keeping.
.travis.yml House keeping.
Gemfile Add gemspec.
Gemfile.lock beta4 House keeping.
Rakefile 1.0.0.beta1
disruptor.gemspec beta4

Build Status

The LMAX Disruptor in Ruby.

The reference Java implementation is more of a framework than a pattern. I have simply taken the core concepts of the Disruptor.

The code may serve as a handy companion for Ruby developers digging into the Disruptor Technical Paper.

There is a simple Queue implementation, if you're after a lock-free queue.

Wait Strategies

  • BusySpinWaitStrategy - Spins until the sequence reaches the required value. CPU intensive but provides best throughput and latency. Do not use if there are more threads than logical CPU cores.
  • BlockingWaitStrategy - Puts waiting threads to sleep. Use this strategy if you have more threads than logical cores.
buffer =,

Cache-line Padding

One neat optimization the LMAX developers have used is cache-line padding of their Sequence object. Replicating this in Ruby is a little tricky as Ruby does not support native types. The problem is made even more tricky when you take into account the different internal Object structure across Ruby implementations. Perhaps a C-ext could achieve this, VM level support would be even better. Patches welcome! ;)


I'm not going to show any results here, because they're pretty meaningless. No Ruby implementation can get close to performance of the Java implementation. If you do want to use the Disruptor pattern in JRuby, you're probably better off writing an extension for the official Disruptor.

Saying that, there are a couple of simple Queue benchmarks in bm.


  • Detect buffer wrap around, have the publishers wait.
  • Implement different processor wait strategies.
  • Implement different publisher claim strategies.
  • Implement cache-line padding (possible on MRI, Rubinius?).
Something went wrong with that request. Please try again.