Re: GSoC ticket #1069 (thread scheduler) application

On 4/11/07, Axel Dörfler <[email protected]> wrote:
> 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.

Assume I meant so as well. You know, I did NOT skip those Operating
Systems classes :D

> 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?

Nevermind that; considering BeOS' threading model, I should have known
better. What I said would make more sense on a very simplified, very
close-to-the-metal, embedded kernel, not on a OS with a threading
model based on semaphores.

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

Right. Landmark here, you finally agreed with something I said... Even
though it's just long-established stuff about algorithmic complexity!
;)

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

Taking into account a conversation I had with Travis last night, if I
happen to win that bet, it would be by a razor-thin margin... OTOH,
I'm relieved to realise my design is EERILY similar to another one he
did last year for an embedded kernel. Of course, his was more
optimized and done some details in a smarter way than I did, but...
It. Was. Just. EERY.

> 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.

Ok, I'll take special care on that part.

> Also, there is no such thing as CPU affinity - which is not really a
> good idea considering the direction x86 is going to.

Seems that Travis and I were considering the same approach to CPU
affinity, so I believe there's a big probability the solutions I
envisioned for Haiku are not totally backwards afterall ;)

I tried not to read any code prior to finishing a couple designs
myself, so I wouldn't be influenced by the status quo of scheduler
design (not that this would be a good or bad thing, I'd probably have
to chande a lot of stuff, I just tried to approach it with no baggage
and perhaps learn a little more about what works and what works not in
the process)... But when geist pointed me to some code of that later
scheduler design he did on his SVN tree, I just thought to myself
"holy mother..." Quite similar approaches, albeit coded in a
considerably distinct way.

> Bye,
>    Axel.

Cheers,
A.

-------------------------------------------------------------------------
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