Is ruby-1.9 threads data safer?

Hello,

$ cat count_threads.rb
class Counter
  attr_reader :count
  def initialize
    @count = 0
  end
  def tick
    @count += 1
  end
end

c = Counter.new
t1 = Thread.new { 10000.times { c.tick } }
t2 = Thread.new { 10000.times { c.tick } }
t1.join
t2.join
puts c.count

$ ruby count_threads.rb
20000
$ ruby count_threads.rb
20000
$ ruby count_threads.rb
20000

My ruby version is 1.9, running under Linux-2.6.31 kernel.
For the code above, though we know the @count isn't safe for sharing.
But the result is always correct.
So can we say ruby-1.9 behaves better on threads than 1.8?

Thanks.

My ruby version is 1.9, running under Linux-2.6.31 kernel.
For the code above, though we know the @count isn't safe for sharing.
But the result is always correct.
So can we say ruby-1.9 behaves better on threads than 1.8?

Nope you just got lucky :slight_smile:
-r

···

--
Posted via http://www.ruby-forum.com/\.

The test proves nothing other than that you got what seems like a proper sum in the end. The runtime could have made accesses to @count atomic - or you could have been lucky (more likely).

It's actually the other way round: if the result would have been != 20000 Ruby 1.9 could be said to behave better on threads than 1.8. The reason is that this would tell you that there are actually concurrent accesses to the same memory, which means there would be more concurrency in 1.9 than in 1.8 with its green threads.

A system which guards accesses to shared resources *without* explicit synchronization would be very bad because it would sacrifice performance without reason.

Kind regards

  robert

···

On 12.03.2010 04:01, Jean G. wrote:

Hello,

$ cat count_threads.rb
class Counter
  attr_reader :count
  def initialize
    @count = 0
  end
  def tick
    @count += 1
  end
end

c = Counter.new
t1 = Thread.new { 10000.times { c.tick } }
t2 = Thread.new { 10000.times { c.tick } }
t1.join
t2.join
puts c.count

$ ruby count_threads.rb
20000
$ ruby count_threads.rb
20000
$ ruby count_threads.rb
20000

My ruby version is 1.9, running under Linux-2.6.31 kernel.
For the code above, though we know the @count isn't safe for sharing.
But the result is always correct.
So can we say ruby-1.9 behaves better on threads than 1.8?

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

We've got a big luck in 1.9 then :wink:

All my tries in 1.8 failed and in 1.9.2 passed

···

On 12 March 2010 18:03, Roger Pack <rogerpack2005@gmail.com> wrote:

> My ruby version is 1.9, running under Linux-2.6.31 kernel.
> For the code above, though we know the @count isn't safe for sharing.
> But the result is always correct.
> So can we say ruby-1.9 behaves better on threads than 1.8?

Nope you just got lucky :slight_smile:
-r
--
Posted via http://www.ruby-forum.com/\.

My suspicion is it has to do with the way threads work in 1.9. Read
http://blog.urbylog.info/2010/01/inside-ruby-19-interpreter-threading-in.html\.
I suspect that the GVL is not released while executing the += operator,
making a real context switch impossible, therefore preventing the other
thread from even running while the assignment is taking place.

Of course you should NOT be counting on the GVL to synchronize your code.

···

On 3/13/2010 7:09 AM, Benoit Daloze wrote:

On 12 March 2010 18:03, Roger Pack <rogerpack2005@gmail.com> wrote:

My ruby version is 1.9, running under Linux-2.6.31 kernel.
For the code above, though we know the @count isn't safe for sharing.
But the result is always correct.
So can we say ruby-1.9 behaves better on threads than 1.8?
      

Nope you just got lucky :slight_smile:
-r
--
Posted via http://www.ruby-forum.com/\.

We've got a big luck in 1.9 then :wink:

All my tries in 1.8 failed and in 1.9.2 passed