I'm saying that in the following code:

That between the first thread starting its 1 second sleep, and the second thread starting its one second sleep, the main thread has to start that second thread. So the differential between thread 1 iterating the shared hash, and thread 2 iterating the shared hash, even on a system that can run all 3 threads immediately and concurrently, has to be at least the time taken to spawn a new thread.

And given I know some of what is involved in spawning a new thread, I find it totally improbable that it would take the first thread longer to iterate the two-key shared hash than it would take the main thread to request the OS to create a new thread, and then go through the process of cloning the spawning threads environment into that new thread.

And that is what it would take for those two threads to be iterating the shared hash concurrently. And that just doesn't add up.

The timing produced by the code above show that with the two threads dumping the hash with a time differential of at minimum, one thread spawn&clone operation apart, the possibility that first thread is still in the progress of iterating the hash when the second thread starts it very unlikely. There is a 3-orders of magnitude differential involved.

C:\test>junk2
0 : 1227891440.24088 } 
0 : 1227891440.26269 } 22 milliseconds to start a thread
0 : 1227891440.26288
0 : 1227891440.28761 } 24 milliseconds to start a thread

1 : 1227891441.27213  }
$VAR1 = {
          'a' => {},
          'b' => {}
        };
1 : 1227891441.27275  } 62 microseconds to dump the hash

2 : 1227891441.28775  }
$VAR1 = {
          'a' => {},
          'b' => {}
        };
2 : 1227891441.28835  } 60 microseconds to dump the hash
[download]