Loops in multiple threads - ruby

Question

I have the following code (from a Ruby tutorial):
require 'thread'
count1 = count2 = 0
difference = 0
counter = Thread.new do
loop do
count1 += 1
count2 += 1
end
end
spy = Thread.new do
loop do
difference += (count1 - count2).abs
end
end
sleep 1
puts "count1 : #{count1}"
puts "count2 : #{count2}"
puts "difference : #{difference}"
counter.join(2)
spy.join(2)
puts "count1 : #{count1}"
puts "count2 : #{count2}"
puts "difference : #{difference}"
It's an example for using Mutex.synchronize. On my computer, the results are quite different from the tutorial. After calling join, the counts are sometimes equal:
count1 : 5321211
count2 : 6812638
difference : 0
count1 : 27307724
count2 : 27307724
difference : 0
and sometimes not:
count1 : 4456390
count2 : 5981589
difference : 0
count1 : 25887977
count2 : 28204117
difference : 0
I don't understand how it is possible that the difference is still 0 even though the counts show very different numbers.
The add operation probably looks like this:
val = fetch_current(count1)
add 1 to val
store val back into count1
and something similar for count2. Ruby can switch execution between threads, so it might not finish writing to a variable, but when the CPU gets back to the thread, it should continue from the line where it was interrupted, right?
And there is still just one thread that is writing into the variable. How is it possible that, inside the loop do block, count2 += 1 is executed much more times?

Answer 1

Execution of
puts "count1 : #{count1}"
takes some time (although it may be short). It is not done in an instance. Therefore, it is not mysterious that the two consecutive lines:
puts "count1 : #{count1}"
puts "count2 : #{count2}"
are showing different counts. Simply, the counter thread went though some loop cycles and incremented the counts while the first puts was executed.
Similarly, when
difference += (count1 - count2).abs
is calculated, the counts may in principle increment while count1 is referenced before count2 is referenced. But there is no command executed within that time span, and I guess that the time it takes to refer to count1 is much shorter than the time it takes for the counter thread to go through another loop. Note that the operations done in the former is a proper subset of what is done in the latter. If the difference is significant enough, which means that counter thread had not gone through a loop cycle during the argument call for the - method, then count1 and count2 will appear as the same value.
A prediction will be that, if you put some expensive calculation after referencing count1 but before referencing count2, then difference will show up:
difference += (count1.tap{some_expensive_calculation} - count2).abs
# => larger `difference`

Answer 2

Here's the answer. I think you've made the assumption that the threads stop execution after join(2) returns.
This is not the case! The threads continue to run even though join(2) returns execution (temporarily) back to the main thread.
If you change your code to this you will see what happens:
...
counter.join(2)
spy.join(2)
counter.kill
spy.kill
puts "count1 : #{count1}"
puts "count2 : #{count2}"
puts "difference : #{difference}"
This seems to work a bit differently in ruby 1.8, where the threads do not seem to get a chance to run while the main thread is executing.
The tutorial is probably written for ruby 1.8, but the threading model has been changed since then in 1.9.
In fact it was pure "luck" that it worked in 1.8, as the threads do not finish execution when join(2) returns in neither 1.8 nor 1.9.