Does ruby have real multithreading?
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).
1. 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.
MRI implements Ruby Threads as Green Threads within its interpreter. Unfortunately, it doesn't allow those
threads to be scheduled in parallel, they can only run one thread at a time. However, any number of C Threads
(POSIX Threads etc.) can run in parallel to the Ruby Thread, so external C Libraries, or MRI C Extensions that
create threads of their own can still run in parallel.
2. The second implementation is YARV (short for "Yet Another Ruby VM"). YARV implements Ruby Threads
as POSIX or Windows NT Threads, however, it uses a Global Interpreter Lock (GIL) to ensure that only one
Ruby Thread can actually be scheduled at any one time. Like MRI, C Threads can actually run parallel to Ruby
Threads. 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.
3. JRuby implements 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.
4. XRuby also implements Ruby Threads as JVM Threads. Update: XRuby is dead.
5. IronRuby implements Ruby Threads as Native Threads, where "Native Threads" in case of the CLRobviously means "CLR Threads". IronRuby imposes no additional locking on them, so, they should run in
parallel, as long as your CLR supports that.
6. Ruby.NET also implements Ruby Threads as CLR Threads. Update: Ruby.NET is dead.
7. Rubinius implements Ruby Threads as Green Threads within its Virtual Machine. More precisely: the
Rubinius VM exports a very lightweight, very flexible concurrency/parallelism/non-local control-flow construct,
called a "Task", and all other concurrency constructs (Threads in this discussion, but also Continuations, Actors
and other stuff) are implemented in pure Ruby, using Tasks.
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.
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).
1. 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.
MRI implements Ruby Threads as Green Threads within its interpreter. Unfortunately, it doesn't allow those
threads to be scheduled in parallel, they can only run one thread at a time. However, any number of C Threads
(POSIX Threads etc.) can run in parallel to the Ruby Thread, so external C Libraries, or MRI C Extensions that
create threads of their own can still run in parallel.
2. The second implementation is YARV (short for "Yet Another Ruby VM"). YARV implements Ruby Threads
as POSIX or Windows NT Threads, however, it uses a Global Interpreter Lock (GIL) to ensure that only one
Ruby Thread can actually be scheduled at any one time. Like MRI, C Threads can actually run parallel to Ruby
Threads. 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.
3. JRuby implements 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.
4. XRuby also implements Ruby Threads as JVM Threads. Update: XRuby is dead.
5. IronRuby implements Ruby Threads as Native Threads, where "Native Threads" in case of the CLRobviously means "CLR Threads". IronRuby imposes no additional locking on them, so, they should run in
parallel, as long as your CLR supports that.
6. Ruby.NET also implements Ruby Threads as CLR Threads. Update: Ruby.NET is dead.
7. Rubinius implements Ruby Threads as Green Threads within its Virtual Machine. More precisely: the
Rubinius VM exports a very lightweight, very flexible concurrency/parallelism/non-local control-flow construct,
called a "Task", and all other concurrency constructs (Threads in this discussion, but also Continuations, Actors
and other stuff) are implemented in pure Ruby, using Tasks.
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.
