[haiku-development] Re: Re : [RFC] Proposal for the new Haiku scheduler
- From: "André Braga" <meianoite@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 13 Jun 2007 15:21:44 -0300
On 6/13/07, Star's seed <starsseed@xxxxxxx> wrote:
Hi
Hi,
A fiber is a thread without processor time. Unix(es) ( or even Windows )
implement
Fibers.( I think Haiku should implement fibers too*.)
I guess you got the definition mixed up.
Fibers are more or less what one would call "userland threads". So,
they have nothing to do with kernel-level scheduling.
You should ask \"What the link with scheduler ?\"
Reading my mind? :)
I think that Haiku should see a thread not only like a thread but even like
a fiber.
I fail to see how that makes any sense. By definition, this can buy us
nothing. As soon as the kernel is aware of fibers in the sense that it
must make scheduling decisions with them, they're no longer fibers,
but threads.
Alas, the only advantage of using fibers is *not* letting the kernel
control the order they execute, but instead a customized "userland"
scheduler is built into your application.
A process being running by the scheduler and giving its running time to an
other
thread(shown as a fiber at this moment), will be able to boost the thread it
wants.
So : A process with a high priority can boost the desktop application in
front ground
with a low priority and so improve interface responsiveness.
This is *very* different from what is supposed to happen with fibers.
But I can see your point.
On his lottery/stride scheduling thesis(*), Waldspurger suggests
having a mechanism to transfer tickets among processes, for example
when several processes are waiting on a semaphore while one is allowed
"inside". The process "inside" the critical session gets boosted by
receiving the tickets from all the other processes blocked on the
semaphore.
This could be emulated (without the IPC overhead) simply by boosting
threads that were allowed to proceed inside the critical session. Axel
tried this already. Didn't work so well, it seems, but maybe it's a
different side effect that hasn't been thoroughly analyzed yet.
I'll eventually stick my nose in and see if I find out why it didn't
perform as expected.
* :
1) Sometimes net servers (like Web servers) control their thread scheduling
themselves for better performaces and then the code is written using
?fibers?
I fail to see many particular uses of fibers that can't be emulated by
"C coroutines"
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
or this:
http://xmailserver.org/libpcl.html
or this:
http://www.sics.se/~adam/pt/about.html
or even converting everything to use "select".
2) Somme Unix fiber based application would be easier to port.
Well, probably, but this is still strictly tied to userland. See
ucontext.h and the related documentation on the unix of your
preference.
Cheers,
A.
Other related posts:
