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.
On Sep 14, 2010, at 10:59 PM, Terry M. wrote:
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
On Wed, Sep 15, 2010 at 12:07 PM, Chuck R. > JRuby 1.5.x and later
No GIL. Native threads. All the concurrency you could possibly want.
nice. is the java code for this open for perusal?
On Tuesday, September 14, 2010 11:07:10 pm Chuck R. wrote:
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.
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.
On 9/14/2010 9:59 PM, Terry M. wrote:
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.
On Tue, Sep 14, 2010 at 9:59 PM, Terry M. [email protected]
wrote:
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 H.
On Wed, Sep 15, 2010 at 7:01 AM, David M. [email protected]
wrote:
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
On 09/14/2010 08:59 PM, Terry M. wrote:
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:
On Tue, Sep 14, 2010 at 10:07 PM, Chuck R.
[email protected]wrote:
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)
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
Oh my friend, i had the same question at you when i studdy the book, is
in “Programming Ruby 1.9.2”. I think the problem become because some
parts of the books are old articles(of previously versions(1.8 for
example)), just a few of them are updated, at simple sight it seems that
Dave(author of the book) doesn’t noted that. I was very confused when i
found the contradiction, so thank’s for ask this.