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
···
On Sep 14, 2010, at 10:59 PM, Terry Michaels wrote:
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.
···
On 9/14/2010 9:59 PM, Terry Michaels wrote:
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.
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
···
On Tue, Sep 14, 2010 at 9:59 PM, Terry Michaels <spare@frigidcode.com> wrote:
Does Ruby have real multi-threading, or is it just context switching?
This is a rather important issue for me.
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.
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 Tuesday, September 14, 2010 11:07:10 pm Chuck Remes wrote:
On Sep 14, 2010, at 10:59 PM, Terry Michaels wrote:
> 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.
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)
···
On Tue, Sep 14, 2010 at 10:07 PM, Chuck Remes <cremes.devlist@mac.com>wrote:
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
···
On Sep 15, 3:20 pm, Kirk Haines <wyhai...@gmail.com> wrote:
On Tue, Sep 14, 2010 at 9:59 PM, Terry Michaels <sp...@frigidcode.com> wrote:
> Does Ruby have real multi-threading, or is it just context switching?
> This is a rather important issue for me.
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.
... 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 Wed, Sep 15, 2010 at 7:01 AM, David Masover <ninja@slaphack.com> wrote:
On Tuesday, September 14, 2010 11:07:10 pm Chuck Remes wrote:
On Sep 14, 2010, at 10:59 PM, Terry Michaels wrote:
> 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.
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.
The first one was pretty