Is ruby-1.9 threads data safer?

Discussion in 'Ruby' started by Jean G., Mar 12, 2010.

  1. Jean G.

    Jean G. Guest

    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.
     
    Jean G., Mar 12, 2010
    #1
    1. Advertising

  2. Jean G.

    Roger Pack Guest


    > 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
    --
    Posted via http://www.ruby-forum.com/.
     
    Roger Pack, Mar 12, 2010
    #2
    1. Advertising

  3. [Note: parts of this message were removed to make it a legal post.]

    On 12 March 2010 18:03, Roger Pack <> 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 :)
    > -r
    > --
    > Posted via 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
     
    Benoit Daloze, Mar 13, 2010
    #3
  4. Jean G.

    Walton Hoops Guest

    On 3/13/2010 7:09 AM, Benoit Daloze wrote:
    > On 12 March 2010 18:03, Roger Pack <> 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 :)
    >> -r
    >> --
    >> Posted via 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
    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.
     
    Walton Hoops, Mar 13, 2010
    #4
  5. 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?


    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


    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Mar 13, 2010
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rag
    Replies:
    0
    Views:
    654
  2. Pradyot Dhulipala

    Writing safer C programs

    Pradyot Dhulipala, Dec 4, 2003, in forum: C Programming
    Replies:
    8
    Views:
    514
    Dan Pop
    Dec 8, 2003
  3. bazad

    Safer and Better C

    bazad, Oct 14, 2004, in forum: C Programming
    Replies:
    40
    Views:
    1,049
    Paul Hsieh
    Oct 26, 2004
  4. Replies:
    5
    Views:
    407
    Arne Vajhøj
    Jun 26, 2008
  5. hemant
    Replies:
    7
    Views:
    140
    Chris Cummer
    Dec 19, 2007
Loading...

Share This Page