Re: Real Time threads
"Axel Dörfler" <[email protected]> Tue, 06 May 2008 14:26:16 +0200 CEST
| Newsgroups | gmane.os.openbeos.kernel.devel |
|---|---|
| Message-ID | <15630872297-BeMail@zon> |
"Salvatore Benedetto" <[email protected]> wrote: > quick questions: how is Haiku supposed to behave with Real Time > threads? > Do we have to do our best, or we have to guarantee what they ask if > we accept > to scheduler them? Or return a message, not a error, if we can't > guarantee what they ask in order to prevent starvation for other > threads. The policy is very simple: is there is a real time thread ready, it is served. Thread starvation should not really be an issue, unless the developer that uses the real time thread is doing something wrong. Anyway, if it's cheap, I would like to have a mechanism that blocks/ punishes/kills real time threads that go nuts in order to make the system usable again. > For example, let's say we have a thread of a 3D shooting game that > ask > to be schedule periodically > in order to render images, and another thread that ask be run > periodically to reproduce the sounds of the game. > And all this are real time threads, or _happen_to_be_ real time > threads( > say we return 120 with suggest_thread_priority). > How should we cope with that? I guess our primary concern is to > avoid > starvation of the other threads anyway right? > But on the other hand, if we accept a thread, we have to guarantee > what they ask. Should we provide some functions > about periodic task like this? If so, we should adopt some kind of > hard real time scheduler for this kind of thread > in order to guarantee what they ask, but also we have to make sure > we > don't create starvation for other backgrounds, low priority > threads. You must only use real time threads when you have to do very time critical stuff that is not very computation intensive. If you have a real time thread that usually needs more than one full quantum, there is probably something wrong with it. As a general rule, the more you have to compute, the lower your priority should be - that's what the scheduler can assume as well. Bye, Axel. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone