Ruby Multi-threading?

[Terry Michaels]

I read a Ruby e-book recently that indicated that although Ruby has
Multi-threading capabilities, it is a fake multi-threading. I.e., the
interpreter simply switches between the executing threads, rather than
running them concurrently.

Then recently I came across an online Ruby tutorial that specifically
said that Ruby threads could be executed in parallel on a multi-core
machine. So I'm a little confused.

Does Ruby have real multi-threading, or is it just context switching?
This is a rather important issue for me.

 

[Chuck Remes]

I read a Ruby e-book recently that indicated that although Ruby has
Multi-threading capabilities, it is a fake multi-threading. I.e., the
interpreter simply switches between the executing threads, rather than
running them concurrently.

Then recently I came across an online Ruby tutorial that specifically
said that Ruby threads could be executed in parallel on a multi-core
machine. So I'm a little confused.

Does Ruby have real multi-threading, or is it just context switching?
This is a rather important issue for me.

Just about any book on this topic will have outdated information. Here's the breakdown.

MRI 1.8.x
Green threads (the "fake" multithreading you mentioned above) that map to a single process thread.

MRI 1.9.x
Native threads. However, most processing is single-threaded because the runtime has a GIL (Global Interpreter Lock) that prevents a lot of concurrency. Each revision of 1.9.x makes the lock more granular for better concurrency.

JRuby 1.5.x and later
No GIL. Native threads. All the concurrency you could possibly want.

Rubinius 1.0.1 and 1.1 (forthcoming)
Contains a GIL and many of the same limitations as 1.9.x. However, a new development branch (hydra) aims to remove the GIL in a near future release. There will still be locks but they will be much more granular.

IronRuby
Not sure.

Maglev
Not sure.


The point of the above is that the picture is constantly changing and each runtime has different characteristics. Have fun exploring.

cr

 

[botp]

No GIL. Native threads. All the concurrency you could possibly want.

nice. is the java code for this open for perusal?

 

[Shashank Tiwari]

[Note: parts of this message were removed to make it a legal post.]

http://jruby.org/git?p=jruby.git;a=summary

 

[Walton Hoops]

I read a Ruby e-book recently that indicated that although Ruby has
Multi-threading capabilities, it is a fake multi-threading. I.e., the
interpreter simply switches between the executing threads, rather than
running them concurrently.

Then recently I came across an online Ruby tutorial that specifically
said that Ruby threads could be executed in parallel on a multi-core
machine. So I'm a little confused.

Does Ruby have real multi-threading, or is it just context switching?
This is a rather important issue for me.

This is a rather confusing issue, but I'll try to give you a basic summary.

MRI 1.8.7: in 1.8.7 green threads are used. This means that the
interpreter is actually managing the context switching, and all
"threads" are running on a single core. This does still mean that one
thread may be waiting on an IO operation, such as reading the disk,
while another thread is running.

MRI 1.9.2: uses native (true) threads. I.E., the different threads MAY
be on different CPU cores. That said, with some exceptions, code is
still not executed in parallel due to the GIL (Global Interpreter
Lock). The basic reason for this is to ease c-extension developers into
truly concurrent threads, which as I understand it is in the starts for
Ruby 2.0.

JRuby: True multi-threading. In JRuby, Ruby threads are Java threads,
and have all the same features and caveats.

Having covered that, I strongly suggest you look into tools for
concurrency via multiple processes, such as Drb (already built into the
language). Shared memory threads tend to be dangerous beasts, and really
aren't needed that often, especially in environments where concurrency
performance is an issue.

 

[David Masover]

Just about any book on this topic will have outdated information. Here's
the breakdown.

Nice summary, mostly accurate. I'd just like to add that, interestingly...

JRuby doesn't have great process management. It has OK process management, but
it seems limited by the JVM. This may be better now, and I may be entirely
wrong, but I wouldn't trust fork here.

With MRI, on the other hand, fork has always worked. The only sticky part is
that no mainstream versions of MRI play nice with COW, which means the entire
process memory _will_ be copied as soon as GC runs.

The usual answer seems to be: Use JRuby if you really want threads, but most
Ruby people care more about scaling to multiple machines more than multicore
on the same machine, at which point it becomes really easy to just spin up a
bunch of MRIs.

 

[Robert Klemme]

Nice summary, mostly accurate. I'd just like to add that, interestingly...

JRuby doesn't have great process management. It has OK process management, but
it seems limited by the JVM. This may be better now, and I may be entirely
wrong, but I wouldn't trust fork here.

With MRI, on the other hand, fork has always worked. The only sticky part is
that no mainstream versions of MRI play nice with COW, which means the entire
process memory _will_ be copied as soon as GC runs.

The usual answer seems to be: Use JRuby if you really want threads, but most
Ruby people care more about scaling to multiple machines more than multicore
on the same machine, at which point it becomes really easy to just spin up a
bunch of MRIs.

... using DRb for example which makes IPC a breeze. Absolutely agree.

Btw, with regard do concurrency: for applications which are IO bound
even MRI's threading model is often sufficient because IO operations
do not block the process but rather give CPU to other threads. The
best is of course to test and benchmark to see whether performance is
sufficient - something true for all kinds of applications and
runtimes.

Kind regards

robert

 

[Kirk Haines]

Does Ruby have real multi-threading, or is it just context switching?
This is a rather important issue for me.

On top of what everyone else has said:

http://www.engineyard.com/blog/2010/concurrency-real-and-imagined-in-mri-threads/

I'm wrapping up a second installment that covers Ruby 1.9 with it's
native threads right now, so that should hit the web site, I am
guessing, next week.


Kirk Haines

 

[Joel VanderWerf]

Does Ruby have real multi-threading, or is it just context switching?
This is a rather important issue for me.

Maybe this is not relevant to your case, but it's also worth
understanding the difference between concurrent and event driven
systems, for example:

http://www.unlimitednovelty.com/2010/08/multithreaded-rails-is-generally-better.html

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

IronRuby
Not sure.

FYI, IronRuby has true concurrent multithreading just like JRuby.

IMO, this approach is great and I'm glad to see Rubinius has it soon (as
Rubinius seems like the easiest upgrade path for people stuck on MRI/YARV
right now)

There are lots of really nifty library-level concurrency solutions popping
up in the Ruby world, but unfortunately without concurrent computation many
of these are not easily useful (e.g. dataflow, omnibus)

 

[Jarmo Pertman]

Kirk, i'm really waiting for that post The first one was pretty
good.

Are you also going to write about DRb or is that just the same as
multiple processes?

Jarmo