Forum: Ruby Thread starvation

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Jakub Pavlík jn. (Guest)
on 2009-01-18 20:06
(Received via mailing list)
Hello,

In my game freeVikings [http://freevikings.sf.net] I have code listed
below.
It uses threads and sometimes problem known as "thread starvation"
occurs.
Does anyone know some solution?
(A more detailed description is under the code listing.)

----------------------------------
def do_loading(&block)
  Thread.abort_on_exception = true

  load_t = Thread.new {
    Thread.current.priority = 1
    Thread.stop

    block.call
  }

  progressbar_t = Thread.new {
    Thread.current.priority = 2
    load_t.run

    loop {
      paint_loading_screen @app_window, true
      sleep 0.3
    }
  }

  load_t.join
  Thread.kill progressbar_t
end
----------------------------------

It's an instance method of class Game and is used in this way:
a_game.do_loading {
  # load something here
}

Purpose of this method is to show a simple progressbar while doing some
long-lasting operation (e.g. loading new level).

It creates two threads: load_t, in which given block is executed
and progressbar_t, which regularly calls Game#paint_loading_screen
(method, which repaints loading screen with progressbar).

Thread progressbar_t has higher priority, because I need it to be called
often and not to e.g. wait for load_t's end.

Unfortunatelly from time to time Thread load_t is somehow "suspended" -
progressbar shows progress on and on, but nothing happens.
I think it's a case of so called "thread starvation" and would be very
glad
to know how to avoid it.

Thank you very much.

Jakub Pavlik

--
"Configure complete, now type 'make' and PRAY."

                (configure script of zsnes - www.zsnes.com)
Robert K. (Guest)
on 2009-01-18 21:15
(Received via mailing list)
On 18.01.2009 19:04, Jakub Pavlík jn. wrote:
>
>
>
> (method, which repaints loading screen with progressbar).
>
> Thread progressbar_t has higher priority, because I need it to be called
> often and not to e.g. wait for load_t's end.
>
> Unfortunatelly from time to time Thread load_t is somehow "suspended" -
> progressbar shows progress on and on, but nothing happens.
> I think it's a case of so called "thread starvation" and would be very glad
> to know how to avoid it.

I guess this depends on what you do in "block".  It's difficult to
analyze this without having all the information...

Can you provide more detail?

Cheers

  robert
Jakub Pavlík jn. (Guest)
on 2009-01-19 11:08
(Received via mailing list)
> >def do_loading(&block)
> >    Thread.current.priority = 2
> >end
> >It creates two threads: load_t, in which given block is executed
>
> remember.guy do |as, often| as.you_can - without end
>

Method do_loading is used for two purposes:
1. loading of a world:
   code in the block goes through a tree of directories and in each
reads
   a XML file
2. loading of a level:
   two XML files (level description & map data created in Tiled) +
   one ruby script (which often requires many others) are loaded from a
   given directory, many graphics are loaded and huge SDL surfaces are
built

Thread starvation usually occurs in the second case.

Jakub

--
"Configure complete, now type 'make' and PRAY."

                (configure script of zsnes - www.zsnes.com)
Robert K. (Guest)
on 2009-01-19 12:22
(Received via mailing list)
2009/1/19 Jakub Pavlík jn. <removed_email_address@domain.invalid>:
>> >def do_loading(&block)
>> >    Thread.current.priority = 2
>> >end
>> >It creates two threads: load_t, in which given block is executed
>>
>   two XML files (level description & map data created in Tiled) +
>   one ruby script (which often requires many others) are loaded from a
>   given directory, many graphics are loaded and huge SDL surfaces are built
>
> Thread starvation usually occurs in the second case.

This is still pretty vague IMHO.  Did you try to trace execution via
set_trace_func?  That might help.

Cheers

robert
This topic is locked and can not be replied to.