Threads Fibers Events and Actors

I presented (from 3000 miles away!) today at EMRubyConf. My talk, “Threads Fibers Events and Actors“, is a short 13min chat on current trends in Ruby scalability and concurrency. To summarize:

Ruby’s threading has historically been terrible. So we turned to event-based systems like EventMachine but the reactor pattern brings its own set of drawbacks. So we turned to Fibers to solve some of those problems but they bring along another set of drawbacks. In the end though, all of this is a workaround for Ruby’s historically terrible threading implementation. But what if Ruby’s threading didn’t suck?

JRuby has great threads. Rubinius will soon have great threads. Both have really matured into excellent, stable runtimes over the last year. Make no mistake threads have issues too; locks and race conditions are notoriously hard to write well and Ruby code can’t be autoloaded safely in a multithreaded system. The former is what Actors attempt to solve: making concurrency simpler and safer by passing messages rather than sharing mutable state and requiring locks.

I think the Ruby community needs to give threads another chance: ensure their gems are thread-safe and use Actors when needing to write safe multithreaded code. Celluloid and the Rubinius Actor API are two APIs which provide Actors to Ruby. My new gem girl_friday leverages actors for safe concurrency. The autoloading problem is the only hard problem remaining; I hope some time and effort can determine ways around this issue.

10 thoughts on “Threads Fibers Events and Actors”

  1. Where can I read up more on the problems of autoloading in threaded ruby?

    Also if we removed autoloading by eager loading all classes in a rails app, the performance hit would only be at boot? which takes a ridiculous amount anyway

  2. The problem with autoload is when two threads encounter an autoloaded constant; very often, one of them can see the related require half-complete and error out.

    1.9.2 fixed this by not removing the autoload constant before requiring, allowing other threads to wait for the require to finish. JRuby supports this on master in 1.9 mode, and if ruby-core fixes it in a 1.8.7 update we will do the same for our 1.8 mode.

  3. Hello,

    I noticed girl_friday has a celluloid branch, and that master is using a patched version of the Rubinius actor API. I am looking at possibly using actors as the concurrency model for a Ruby project and was wondering if you could tell me the main reasons(s) for embedding the Rubinius actor code as opposed to using celluloid? Did celluloid have characteristics that made it unsuitable for girl_friday?

  4. Nathan, that’s a possible future direction of girl_friday that Tony is working on. Consider it unsupported alpha software at the moment. If you just want to use girl_friday, stick with master.

  5. EventMachine, aka event driven io, is NOT a reaction to Ruby’s threading woes. Ignore Ruby, or Java, or, language dujour. Even C at the user space/kernel layer is where you find out that threads-are-slow, events-are-fast. More precisely, blocking io is slow and non-blocking io is fast. Threads exist to hide that “n = read(fd, buf, len)” blocks. Thread give you the illusion that this doesn’t matter because you can do other work in parallel. Event IO allows you to explicitly do other work while waiting for IOs to complete (node.js is brilliant at forcing programmers to grok this). Threads require context switches, which are invisible to the user-space programmers, but consume a great deal of overhead in actuality.
    Fibers are not a compensation for bad thread performance either. At its basic level, a fiber is swapping out the stack pointer and a long jump to a new call stack. A thread switch, even on Linux which is brutally fast, is about a 100 instruction for the trampoline and you blow your TLB and other memory optimizations. Just benchmark JRuby Fibers (which uses Threads) versus MRI Fibers; that is a remarkably good test of thread context switches against a few user space stack tricks for Fibers & coroutines.
    I beg your pardon if this degenerated into a rant, but it is one of my pet-peeves. I’ve worked at AOL and Amazon doing massively scalable architectures and even a these companies you see programmers coming from “Learn X in 21 days” books, which say “accept a socket and spawn a thread then read/write to your hearts desire”.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>