Re: Ruby and threading

On Wed, Oct 26, 2011 at 8:59 PM, Charles Oliver Nutter
<[e-mail]>wrote:

> On Wed, Oct 19, 2011 at 2:11 AM, Josh Cheek <[e-mail]> wrote:
> > A great followup to this post, explains why the GIL exists
> > http://merbist.com/2011/10/18/data-safety-and-gil-removal/
> >
> > When I ran the code Matt provides under MRI 1.9.3 (has GIL) and Rubinius,
> > JRuby, MacRuby (native threads, no GIL):
>
> Ok, I can't let this one sit.
>
>
Hi, Charlie, hope you aren't taking this as a criticism of JRuby, it's just
intended to point out what the GIL does, since many people don't seem to
understand it's purpose.


> For a run that short, I'm not surprised. JRuby would be faster if it
> ran for more than...what...0.07 seconds? I ran a longer version
> without threads (so it wouldn't error out) and JRuby was clearly the
> fastest. I also wrote a version that uses a JRuby-specific module for
> thread-safety, and it only slowed down by about 2x...but it completes
> successfully every time:
>
> require 'jruby/synchronized'
> puts '', ENV['RUBY_VERSION']
>
> class SafeArray < Array
>  include JRuby::Synchronized
> end
>
> 10.times do
>  @array, threads = SafeArray.new, []
>   start = Time.now
>  4.times do
>   threads << Thread.new { (1..100_000).each {|n| @array << n} }
>  end
>  threads.each{|t| t.join }
>  stop = Time.now
>
>  puts "%0.3f seconds" % (stop - start), @array.size
> end
>
>
nice!


> > Thoughts:
> > * MRI has a GIL, thus keeping the data safe, and still performs
> equivalently
> > with other implementations (for this admittedly limited test), so do
> > benchmarks to decide if this will be worthwhile. It's not a fluke that
> Matz
> > wants to keep the GIL.
>
> False safety (you can still easily have threads step on each other) at
> the expense of parallelism. I'm not sure that's a win.
>
> Also, I don't think Matz has ever said he really "wants" to keep the
> GIL. It's just a massively difficult thing to retrofit MRI for
> parallel threading without a very large rework. If they could drop the
> GIL without destabilizing MRI itself, I'm sure they'd do it.
>
>
I'm sure they would, too. But people seem to think it was a whimsical
decision. I'm just saying it isn't, that it's that way for a reason, and
showing what the reason is. Debating over the phrase "want" seems pedantic.


> > * I'm glad JRuby notices the corrupt data (though not always) I'm a big
> fan
> > of fail-fast
>
> It only fails fast if it actually fails, of course. Some of your runs
> manage to succeed without the threads stepping on each other. And by
> failure, here, I mean potentially corrupting the array. The array
> contents may get out of sync because you don't synchronize writes, but
> that's not a failure in a concurrent environment. Or at least, it's
> not JRuby's failure...it's yours.
>
>
I'm not saying JRuby failed (perhaps I'm not communicating well, as you're
not the only person to take it this way). I'm saying the behaviour is
different in a way that could easily bite someone, and showing an
example. As to whether I failed in writing this code, the code came from
http://merbist.com/2011/10/18/data-safety-and-gil-removal/ (as stated
previously) and it's purpose is to reveal this issue.


> > * Has JRuby fixed their startup time issue? I ran this a lot of times and
> > didn't notice any of the lag I used to.
>
> That's good to hear! Every release includes more startup-time tweaks.
> Perhaps we're finally "getting there".
>
>
Glad to hear it, that's the primary (and only noteworthy) reason that JRuby
isn't my default implementation.



As an aside, if I had a real need for parallelism, I'd probably select a
language better suited to it (e.g. Clojure). Maybe if the community offered
some good resources about how to safely develop parallel code I'd be more
comfortable using Ruby, but right now, I prefer the safety of the GIL.