Hi Pit,

thanks again for the response. I backgraded to Ruby 1.8.6 to make some
tests too, the behavior is as you have described it. Here the test
code I have used:


  Thread.main.priority = 0
  count1 = count2 = 0

  a = Thread.new do
    puts "starting thread a"
    Thread.current.priority = -1
    loop { count1 += 1 }
  end

  b = Thread.new do
    puts "starting thread b"
    Thread.current.priority = -1
    loop { count2 += 1}
  end

  puts "stalling main thread for 1 second"
  sleep 1

  a.kill; b.kill
  puts "count1: #{count1}"
  puts "count2: #{count2}"


On Ruby 1.8.6 I get the following output:

  starting thread a
  starting thread b
  stalling main thread for 1 second
  count1: 953760
  count2: 953753


So this is fine and what I expected (if I lower thread b priority to
-2, count2 drop to absolute 0. This is quite awful, but ok, I'll stop
complaining ;-). On Ruby 1.8.7 however, I just see:

  starting thread a
  starting thread b
  stalling main thread for 1 second

No more output from here on. It seems that the sleep statement does not return.

Thanks however for your help.

Regards
Daniel


On 8/21/08, Pit Capitain <pit.capitain / gmail.com> wrote:
> Hi Daniel.
>
>> The behaviour I expect from threads in general is that they virtually run
>> in
>> parallel. So I expect each active thread to be at least scheduled, but not
>> blocked, even if it has a low priority.
>
> From looking at the source code of 1.8.6 and from running some tests
> this doesn't seem to be the case. Threads with lower priority are
> blocked as long as there are runnable threads with higher priority.
>
>> If there is a total of two threads
>> that have the same priority, I expect the thread scheduler to assign 50%
>> of
>> processing resources to each of them. In earlier Ruby versions (e.g.
>> 1.8.6),
>> this is exactly what has happened.
>
> Indeed this seems to be the case in 1.8.6, again from looking at the
> source and running some tests. If this doesn't work in Ruby 1.8.7, you
> should perhaps report it on ruby-core.
>
>> I could reach that behavior in the example before (which is as I stated an
>> "official" one, since you can also find it in the only ruby core
>> documentation of the thread class:
>> http://www.ruby-doc.org/core/classes/Thread.html#M000480) by inserting
>> sleep
>> statements into the loop-blocks.
>
> AFAIK there's no official description of Ruby yet. There are projects
> trying to fill this gap with executable specifications.
>
>> I could then control the amount of
>> processing time for each thread by balancing the sleep times, therefore
>> emulating priority. But then I would mimic the behavior that usually rubys
>> thread scheduler should perform for me.
>
> I don't buy this "should". The documentation you've cited clearly
> says, that higher-priority threads will run before lower-priority
> threads.
>
> Regards,
> Pit
>
>