# Is ruby-1.9 threads data safer?

**URL:** <https://www.ruby-forum.com/t/is-ruby-1-9-threads-data-safer/185032>\
**Category:** Ruby\
**Created:** [March 12, 2010, 4:02am UTC](https://www.ruby-forum.com/t/is-ruby-1-9-threads-data-safer/185032 "2010-03-12T04:02:51Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jean\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ccd318/32.png) [@Jean\_G](https://www.ruby-forum.com/u/Jean_G)\
**Post date:** [March 12, 2010, 4:02am UTC](https://www.ruby-forum.com/t/is-ruby-1-9-threads-data-safer/185032/1 "2010-03-12T04:02:51Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Jean\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ccd318/32.png) [@Jean\_G](https://www.ruby-forum.com/u/Jean_G)\
**Post date:** [March 12, 2010, 6:03pm UTC](https://www.ruby-forum.com/t/is-ruby-1-9-threads-data-safer/185032/2 "2010-03-12T18:03:07Z")

</div>

> 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 🙂  
-r

---

<div class="post-metadata">

**Author:** ![Jean\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ccd318/32.png) [@Jean\_G](https://www.ruby-forum.com/u/Jean_G)\
**Post date:** [March 13, 2010, 3:09pm UTC](https://www.ruby-forum.com/t/is-ruby-1-9-threads-data-safer/185032/3 "2010-03-13T15:09:50Z")

</div>

On 12 March 2010 18:03, Roger P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> 

We’ve got a big luck in 1.9 then 😉

All my tries in 1.8 failed and in 1.9.2 passed

---

<div class="post-metadata">

**Author:** ![Jean\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ccd318/32.png) [@Jean\_G](https://www.ruby-forum.com/u/Jean_G)\
**Post date:** [March 13, 2010, 5:18pm UTC](https://www.ruby-forum.com/t/is-ruby-1-9-threads-data-safer/185032/4 "2010-03-13T17:18:02Z")

</div>

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

> > ## -r
> > 
> > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/).
> 
> We’ve got a big luck in 1.9 then 😉
> 
> All my tries in 1.8 failed and in 1.9.2 passed

My suspicion is it has to do with the way threads work in 1.9. Read  
[urby by ub: Inside Ruby 1.9 interpreter: Threading in Ruby 1.9.1](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.

---

<div class="post-metadata">

**Author:** ![Jean\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ccd318/32.png) [@Jean\_G](https://www.ruby-forum.com/u/Jean_G)\
**Post date:** [March 13, 2010, 8:05pm UTC](https://www.ruby-forum.com/t/is-ruby-1-9-threads-data-safer/185032/5 "2010-03-13T20:05:26Z")

</div>

On 12.03.2010 04:01, Jean G. wrote:

> end  
> 20000  
> So can we say ruby-1.9 behaves better on threads than 1.8?  
> 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