It looks like I got too creative in 0.6.1 and consequently ran afoul of
a bug in the Ruby interpreter. 0.6.2 works around the bug and should be
entirely stable at this point.
Thanks to Young H. for his help in coming up with test cases.
fastthread is a Ruby library which provides a faster (and
non-memory-leaking) C implementation of the concurrency primitives from
stdlib’s thread.rb. It aims to be 100% compatible with thread.rb’s
So, how much faster? In the single-threaded case, fastthread’s version
of Mutex#lock and Mutex#synchronize are comparable in performance to
Thread.critical= and Thread.exclusive. With multiple threads, it has an
additional advantage over Thread.critical in that entering a critical
section doesn’t suspend any other threads unless they’re competing for
the same lock. (Compare that to Thread.critical, which stops all other
I know a lot of folks have been avoiding stdlib’s Mutex because all the
method calls killed performance. But no more, with fastthread! Why use
Thread.critical when you can use the real thing?
Simply require ‘fastthread’ in addition to ‘thread’. If you want to
make fastthread optional (recommended!), do it this way:
require 'thread' begin require 'fastthread' rescue LoadError end
This way, your program will still work on systems that don’t have (or
don’t need – e.g. JRuby) fastthread, but you still get a performance
boost on systems where it’s available.
fastthread is also available on Rubyforge (and therefore the main gems
repository), courtesy of the Mongrel project: