[ruby-core:43007] Re: 50$ for answering my stackoverflow question about Ruby and GIL

Sorry, my english is not very good, i can't understand this :(. Adding
"1" to the list is a fast operation. Amount of "1" and "2" in the list
is ~ same. Number of probes is very high, > 10 millions. I can't
figure out WHAT can happen with concurrency other than big splice size
in order for thousands of "1" to be followed by thousands of "2" for
10 seconds of test. Of course physical threads may switch multiple
times, but i'm counting only ruby code execution, regardless of
"physical threads" or "green threads".

Best,
Grigory.

On Tue, Feb 28, 2012 at 8:07 PM, Eric Hodel <[e-mail]> wrote:
> On Feb 28, 2012, at 2:43, Grigory Petrov <[e-mail]> wrote:
>
>>> This test code doesn't show switch time, it shows how fast two ruby threads can append items to a list. ach thread may switch multiple times during appending the item, or may not switch at all, but resume executing the same thread.
>>
>> Ok, i spelled it incorrectly. The test code shows amount of time a
>> Ruby thread is working before scheduler suspends it (due to GIL) and
>> gives time to another Ruby thread. This may or may not correlate with
>> physical threads - i'm not very good with Ruby scheduling code on
>> different OS'es.
>>
>> For example, if resulting list looks like [ 1, 2, 1, 2, 1, 2, 1, 2, 1,
>> 2, 1, 2 ] i can say that scheduler gives threads a small splice. And
>> if resulting list looks like [ 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2 ] =
>> splice is big.
>
> You can't draw that conclusion from the output since you don't know if thread 2 ran between the third and fourth 1 in the Array, but not long enough to append a 2 to the list.
>