# Ruby Multi-threading? **URL:** \ **Category:** Ruby\ **Created:** [September 15, 2010, 5:59am UTC](https://www.ruby-forum.com/t/ruby-multi-threading/194995 "2010-09-15T05:59:31Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![callyworld](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/f17d59/32.png) [@callyworld](https://www.ruby-forum.com/u/callyworld)\ **Post date:** [September 15, 2010, 5:59am UTC](https://www.ruby-forum.com/t/ruby-multi-threading/194995/1 "2010-09-15T05:59:31Z")
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. ---
**Author:** ![callyworld](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/f17d59/32.png) [@callyworld](https://www.ruby-forum.com/u/callyworld)\ **Post date:** [September 15, 2010, 6:07am UTC](https://www.ruby-forum.com/t/ruby-multi-threading/194995/2 "2010-09-15T06:07:32Z")
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 ---
**Author:** ![callyworld](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/f17d59/32.png) [@callyworld](https://www.ruby-forum.com/u/callyworld)\ **Post date:** [September 15, 2010, 6:12am UTC](https://www.ruby-forum.com/t/ruby-multi-threading/194995/3 "2010-09-15T06:12:13Z")
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? ---
**Author:** ![callyworld](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/f17d59/32.png) [@callyworld](https://www.ruby-forum.com/u/callyworld)\ **Post date:** [September 15, 2010, 6:15am UTC](https://www.ruby-forum.com/t/ruby-multi-threading/194995/4 "2010-09-15T06:15:44Z")
[http://jruby.org/git?p=jruby.git;a=summary](http://jruby.org/git?p=jruby.git;a=summary) ---
**Author:** ![callyworld](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/f17d59/32.png) [@callyworld](https://www.ruby-forum.com/u/callyworld)\ **Post date:** [September 15, 2010, 7:02am UTC](https://www.ruby-forum.com/t/ruby-multi-threading/194995/5 "2010-09-15T07:02:33Z")
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. ---
**Author:** ![callyworld](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/f17d59/32.png) [@callyworld](https://www.ruby-forum.com/u/callyworld)\ **Post date:** [September 15, 2010, 6:18am UTC](https://www.ruby-forum.com/t/ruby-multi-threading/194995/6 "2010-09-15T06:18:05Z")
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. ---
**Author:** ![callyworld](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/f17d59/32.png) [@callyworld](https://www.ruby-forum.com/u/callyworld)\ **Post date:** [September 15, 2010, 2:21pm UTC](https://www.ruby-forum.com/t/ruby-multi-threading/194995/7 "2010-09-15T14:21:01Z")
On Tue, Sep 14, 2010 at 9:59 PM, Terry M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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/](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. ---
**Author:** ![callyworld](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/f17d59/32.png) [@callyworld](https://www.ruby-forum.com/u/callyworld)\ **Post date:** [September 15, 2010, 9:15am UTC](https://www.ruby-forum.com/t/ruby-multi-threading/194995/8 "2010-09-15T09:15:26Z")
On Wed, Sep 15, 2010 at 7:01 AM, David M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![callyworld](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/f17d59/32.png) [@callyworld](https://www.ruby-forum.com/u/callyworld)\ **Post date:** [September 15, 2010, 7:50pm UTC](https://www.ruby-forum.com/t/ruby-multi-threading/194995/9 "2010-09-15T19:50:38Z")
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: > **[Multithreaded Rails is generally better than Async Rails, and Rainbows is...](http://www.unlimitednovelty.com/2010/08/multithreaded-rails-is-generally-better.html)** > > Once upon a time Rails was single threaded and could only process one request at a time. This meant for each concurrent request you wanted t... ---
**Author:** ![callyworld](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/f17d59/32.png) [@callyworld](https://www.ruby-forum.com/u/callyworld)\ **Post date:** [September 15, 2010, 11:16pm UTC](https://www.ruby-forum.com/t/ruby-multi-threading/194995/10 "2010-09-15T23:16:42Z")
On Tue, Sep 14, 2010 at 10:07 PM, Chuck R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)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) ---
**Author:** ![callyworld](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/f17d59/32.png) [@callyworld](https://www.ruby-forum.com/u/callyworld)\ **Post date:** [September 25, 2010, 11:40am UTC](https://www.ruby-forum.com/t/ruby-multi-threading/194995/11 "2010-09-25T11:40:24Z")
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 ---
**Author:** ![callyworld](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/f17d59/32.png) [@callyworld](https://www.ruby-forum.com/u/callyworld)\ **Post date:** [May 23, 2012, 12:00am UTC](https://www.ruby-forum.com/t/ruby-multi-threading/194995/12 "2012-05-23T00:00:20Z")
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. 🙂