Re: GSoC ticket #1069 (t hread scheduler) application

"André Braga" <[email protected]> wrote:
> On 4/10/07, Axel Dörfler <[email protected]> wrote:
> > Please have a look at the current scheduler to see how it's 
> > supposed to
> > work: whenever a thread is scheduled to run, a timer interrupt is
> > started that defines the quantum of the thread (currently fixed 3 
> > ms).
> > But this quantum can get cut if the thread decides to block; in 
> > that
> > case, the scheduler is invoked directly, and the quantum timer is
> > aborted.
> That was exactly what I wrote, except that I left out the details, 
> no?
> "I assume the scheduler still runs at regular intervals, and it will
> just allow the current RT thread to run unless blocked or a
> higher-priority one becomes ready."

Maybe you meant the same, but I can't read it out of those lines ;-)
Even if a higher priority thread becomes ready, a thread is never 
interrupted (unless it choses to, or a hardware interrupt happens) 
before it has fulfilled its quantum.

> > But anyway, you cannot know why a thread is waiting or what it is
> > waiting for - the kernel only knows threads that wait on a 
> > semaphore or
> > not (neglecting suspended threads here).
> Ok... I didn't know that everything gets abstracted by semaphores 
> even
> at the kernel level. I believed there could be some mechanism to tell
> the kernel what susbsystem a semaphore belongs to, and that we could
> use such knowledge.

I don't even understand what you wanted to do with this knowledge; what 
would be the advantage to know that a certain thread is waiting for I/O 
instead of a message of its pal?

[...]
> > Count two threads per window, one for each application. All in all,
> > there should rarely be more than 1000 threads active at some point;
> > BeOS even has a hard 4096 thread limit (Haiku currently limits the
> > number of threads to the same amount).
> Okay... Just FWIW, whenever we need to transpass this limit, we may, 
> with ease.

Well, as you correctly said, scalability is the idea behind an O(1) 
algorithm.

> Still, that's indeed a benchmark I'm yet to run. Are you willing to
> bet a sixpack that I'll be able to outperform the current scheduler
> EVERY time the number of ready threads is larger than 2? ;)

I'm not saying that our current scheduler couldn't be sped up, but as 
long as BGA delivers it to you ;-)

> > Currently, there are usually less than 5 threads in the run queue; 
> > but
> > you can easily test that with a small application. Only inserting
> > threads into the run queue is currently O(n), the rest of the 
> > scheduler
> > already is O(1).
> So it's in a greater shape than I originally imagined. Anyway, I just
> thought it would be better to target a very large value that's easily
> downscaled than assume small values and have a hard time upscaling
> them when the need arises.

It should be in an acceptable shape; it's pretty much exactly what BeOS 
did. However, there seem to be some issues with it that I didn't look 
into yet; thread starvation is a big issue for some reason, and that 
doesn't seem to be right.
Also, there is no such thing as CPU affinity - which is not really a 
good idea considering the direction x86 is going to.

Bye,
   Axel.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV