9 Answers
9

You seem to be confusing two very different things here: the
Ruby Programming Language and the specific threading model of one
specific implementation of the Ruby Programming Language. There
are currently around 11 different implementations of the Ruby
Programming Language, with very different and unique threading
models.

(Unfortunately, only two of those 11 implementations are actually
ready for production use, but by the end of the year that number
will probably go up to four or five.) (Update: it's now 5: MRI, JRuby, YARV (the interpreter for Ruby 1.9), Rubinius and IronRuby).

The first implementation doesn't actually have a name, which
makes it quite awkward to refer to it and is really annoying and
confusing. It is most often referred to as "Ruby", which is even
more annoying and confusing than having no name, because it
leads to endless confusion between the features of the Ruby
Programming Language and a particular Ruby Implementation.

It is also sometimes called "MRI" (for "Matz's Ruby
Implementation"), CRuby or MatzRuby.

In the future, it is possible, that the GIL might get broken
down into more fine-grained locks, thus allowing more and more
code to actually run in parallel, but that's so far away, it is
not even planned yet.

JRubyimplements Ruby Threads as Native Threads,
where "Native Threads" in case of the JVM obviously means "JVM
Threads". JRuby imposes no additional locking on them. So,
whether those threads can actually run in parallel depends on
the JVM: some JVMs implement JVM Threads as OS Threads and some
as Green Threads. (The mainstream JVMs from Sun/Oracle use exclusively OS threads since JDK 1.3)

Rubinius can not (currently) schedule Threads in parallel,
however, adding that isn't too much of a problem: Rubinius can
already run several VM instances in several POSIX Threads in
parallel, within one Rubinius process. Since Threads are
actually implemented in Ruby, they can, like any other Ruby
object, be serialized and sent to a different VM in a different
POSIX Thread. (That's the same model the BEAM Erlang VM
uses for SMP concurrency. It is already implemented for
Rubinius Actors.)

Update: The information about Rubinius in this answer is about the Shotgun VM, which doesn't exist anymore. The "new" C++ VM does not use green threads scheduled across multiple VMs (i.e. Erlang/BEAM style), it uses a more traditional single VM with multiple native OS threads model, just like the one employed by, say, the CLR, Mono, and pretty much every JVM.

MacRuby started out as a port of YARV on top of the
Objective-C Runtime and CoreFoundation and Cocoa Frameworks. It
has now significantly diverged from YARV, but AFAIK it currently
still shares the same Threading Model with YARV.
Update: MacRuby depends on apples garbage collector which is declared deprecated and will be removed in later versions of MacOSX, MacRuby is undead.

MagLev is a Ruby Implementation for the GemStone/S
Smalltalk VM. I have no information what threading model
GemStone/S uses, what threading model MagLev uses or even if
threads are even implemented yet (probably not).

HotRuby is not a full Ruby Implementation of its
own. It is an implementation of a YARV bytecode VM in
JavaScript. HotRuby doesn't support threads (yet?) and when it
does, they won't be able to run in parallel, because JavaScript
has no support for true parallelism. There is an ActionScript
version of HotRuby, however, and ActionScript might actually
support parallelism. Update: HotRuby is dead.

Unfortunately, only two of these 11 Ruby Implementations are
actually production-ready: MRI and JRuby.

So, if you want true parallel threads, JRuby is currently your
only choice – not that that's a bad one: JRuby is actually faster
than MRI, and arguably more stable.

Otherwise, the "classical" Ruby solution is to use processes
instead of threads for parallelism. The Ruby Core Library
contains the Process module with the Process.fork
method which makes it dead easy to fork off another Ruby
process. Also, the Ruby Standard Library contains the
Distributed Ruby (dRuby / dRb) library, which allows Ruby
code to be trivially distributed across multiple processes, not
only on the same machine but also across the network.

Ruby 1.8 only has green threads, there is no way to create a real "OS-level" thread. But, ruby 1.9 will have a new feature called fibers, which will allow you to create actual OS-level threads. Unfortunately, Ruby 1.9 is still in beta, it is scheduled to be stable in a couple of months.

Another alternative is to use JRuby. JRuby implements threads as OS-level theads, there are no "green threads" in it. The latest version of JRuby is 1.1.4 and is equivalent to Ruby 1.8

It's false that Ruby 1.8 has only green threads, several implementations of Ruby 1.8 have native threads: JRuby, XRuby, Ruby.NET and IronRuby. Fibers don't allow the creation of native threads, they are more lightweight than threads. They are actually semi-coroutines, i.e. they are cooperative.
– Jörg W MittagSep 11 '08 at 22:32

18

I think it's pretty obvious from Josh's answer that he means Ruby 1.8 the runtime, a.k.a. MRI, and not Ruby 1.8 the language, when he says Ruby 1.8.
– TheoApr 22 '11 at 19:46

@Theo It's also obvious that he messes up concepts in his answer. Fibers are not a way to create native threads, as already mentioned, they are even more lightweight things than threads and current cruby has native threads but with GIL.
– Foo Bar ZooDec 30 '18 at 19:51

I'll let the "System Monitor" answer this question. I'm executing the same code (below, which calculates prime numbers) with 8 Ruby threads running on an i7 (4 hyperthreaded-core) machine in both cases... the first run is with:

Interestingly, the CPU is higher for JRuby threads, but the time to completion is slightly shorter for the interpreted Ruby. It's kind of difficult to tell from the graph, but the second (interpreted Ruby) run uses about 1/2 the CPUs (no hyperthreading?)

If you really need parallelism in Ruby for a Production level system (where you cannot employ a beta) processes are probably a better alternative.
But, it is most definitely worth trying threads under JRuby first.

Also if you are interested in future of threading under Ruby, you might find this article useful.

This article is very old, and information is not follow current
(2017) tread, Following is some supplement:

Opal is a Ruby to JavaScript source-to-source compiler. It also has an implementation of the Ruby corelib, It current very active develompent, and exist a great deal of (frontend) framework worked on it.
and production ready. Because base on javascript, it not support parallel threads.

truffleruby is a high performance implementation of the Ruby programming language. Built on the GraalVM by Oracle Labs,TruffleRuby is a fork of JRuby, combining it with code from the Rubinius project, and also containing code from the standard implementation of Ruby, MRI, still live development, not production ready.
This version ruby seem like born for performance, I don't know if support parallel threads, but I think it should.