Digging Deeper

Here you will learn how to pass execution from one thread to another. You will discover some things that the Ruby documentation doesn’t tell you and some oddities about different versions of Ruby.

Passing Execution to Other Threads

Sometimes you might specifically want a certain thread to yield execution to any other threads that happen to be running. For example, if you have multiple threads doing steadily updated graphics operations or displaying various bits of “as it happens” statistical information, you may want to ensure that once one thread has drawn X number of pixels or displayed Y number of statistics, the other threads are guaranteed to get their chances to do something.

In theory, the Thread.pass method takes care of this. Ruby’s source code documentation states that Thread.pass “invokes the thread scheduler to pass execution to another thread.” This is the example provided by the Ruby documentation:

pass0.rb

a = Thread.new {    print "a"; Thread.pass;
                    print "b"; Thread.pass;
                    print "c" }
b = Thread.new {    print "x"; Thread.pass;
                    print "y"; Thread.pass;
                    print "z" }
a.join
b.join

According to the documentation, this code, when run, produces the output axbycz. And, sure enough, it does. In theory, then, this seems to show that by calling Thread.pass after each call to print, these threads pass execution to another thread, which is why the output from the two threads alternates.

Being of a suspicious turn of mind, I wondered what the effect would be with the calls to Thread.pass removed. Would the first thread hog all the time, yielding to the second thread only when it has finished? The best way to find out is to try it:

pass1.rb

a = Thread.new {    print "a";
                    print "b";
                    print "c" }
b = Thread.new {    print "x";
                    print "y";
                    print "z" }
a.join
b.join

If my theory is correct (that thread a will hog all the time until it’s finished), this would be the expected output: abcdef. In fact (to my surprise!), the output actually produced was axbycz.

In other words, the result was the same with or without all those calls to Thread.pass. So what, if anything, is Thread.pass doing? And is the documentation wrong when it claims that the pass method invokes the thread scheduler to pass execution to another thread?

For a brief and cynical moment I confess that I toyed with the possibility that the documentation was simply incorrect and that Thread.pass didn’t do anything at all. A look into Ruby’s C-language source code soon dispelled my doubts; Thread.pass certainly does something, but its behavior is not quite as predictable as the Ruby documentation seems to suggest. Before explaining why this is, let’s try an example of my own:

pass2.rb

s = 'start '
a = Thread.new { (1..10).each{
    s << 'a'
    Thread.pass
    }
}
b = Thread.new { (1..10).each{
    s << 'b'
    Thread.pass
    }
}

a.join
b.join
puts( "#{s} end" )

At first sight, this may look very similar to the previous example. It sets two threads running, but instead of printing out something repeatedly, these threads repeatedly add a character to a string—“a” being added by the a thread and “b” by the b thread. After each operation, Thread.pass passes execution to the other thread. At the end, the entire string is displayed. When run with Ruby 1.8, it comes as no surprise that the string contains an alternating sequence of “a” and “b” characters: abababababababababab. However, in Ruby 1.9, the characters do not alternate, and this is what I see: aaaaaaaaaabbbbbbbbbb. In my view, the pass method is not to be trusted with Ruby 1.9, and the remaining discussion applies to Ruby 1.8 only.

Now, remember that in the previous program, I obtained the same alternating output even when I removed the calls to Thread.pass. Based on that experience, I guess I should expect similar results if I delete Thread.pass in this program. Let’s try it:

pass3.rb

s = 'start '
a = Thread.new { (1..10).each{
    s << 'a'
    }
}
b = Thread.new { (1..10).each{
    s << 'b'
    }
}

a.join
b.join
puts( "#{s} end" )

This time, this is the output: aaaaaaaaaabbbbbbbbbb.

In other words, this program shows the kind of differing behavior that I had originally anticipated in the first program (the one I copied out of Ruby’s embedded documentation), which is to say that when the two threads are left to run under their own steam, the first thread, a, grabs all the time for itself and only when it’s finished does the second thread, b, get a look in. But by explicitly adding calls to Thread.pass in Ruby 1.8, you can force each thread to pass execution to any other threads.

So, how can you explain this difference in behavior? In essence, pass0.rb and pass3.rb are doing the same things—running two threads and displaying strings from each. The only real difference is that, in pass3.rb, the strings are concatenated inside the threads rather than printed. This might not seem like a big deal, but it turns out that printing a string takes a bit more time than concatenating one. In effect, then, a call to print introduces a time delay. And as you found out earlier (when I deliberately introduced a delay using sleep), time delays have profound effects on threads.

If you still aren’t convinced, try my rewritten version of pass0.rb, which I have creatively named pass0_new.rb. This simply replaces the prints with concatenations. Now if you comment and uncomment the calls to Thread.pass, you will indeed, in Ruby 1.8, see differing results:

pass0_new.rb

s = ""
a = Thread.new { s << "a"; Thread.pass;
    s << "b"; Thread.pass;
    s << "c" }

b = Thread.new { s << "x"; Thread.pass;
    s << "y"; Thread.pass;
    s << "z" }

a.join
b.join
puts( s )

With Thread.pass, Ruby 1.8 displays the following:

axbycz

Without Thread.pass, Ruby 1.8 displays the following:

abcxyz

In Ruby 1.9, the presence or absence of Thread.pass has no obvious effect. And, with or without it, this is displayed:

abcxyz

Incidentally, my tests were conducted on a PC running Windows. It is quite possible that different results will be seen on other operating systems. This is because the implementation of the Ruby scheduler, which controls the amount of time allocated to threads, is different on Windows and other operating systems.

As a final example, you may want to take a look at the pass4.rb program, which is intended for Ruby 1.8 only. This creates two threads and immediately suspends them (Thread.stop). In the body of each thread the thread’s information, including its object_id is appended to an array, arr, and then Thread.pass is called. Finally, the two threads are run and joined, and the array, arr, is displayed. Try experimenting by uncommenting Thread.pass to verify its effect (pay close attention to the execution order of the threads as indicated by their object_id identifiers):

pass4.rb

arr = []
t1 = Thread.new{
    Thread.stop
    (1..10).each{
        arr << Thread.current.to_s
        Thread.pass
    }
}
t2 = Thread.new{
    Thread.stop
    (1..10).each{ |i|
        arr << Thread.current.to_s
        Thread.pass
    }
}
puts( "Starting threads..." )
t1.run
t2.run
t1.join
t2.join
puts( arr )