Re: [Linux-ia64] Re: web page on O(1) scheduler

[Mike Galbraith <efault@gmx.de>]

At 06:12 PM 5/28/2003 -0400, Bill Davidsen wrote:
>On Wed, 21 May 2003, Olivier Galibert wrote:
>
> > On Wed, May 21, 2003 at 03:12:12PM +0200, Arjan van de Ven wrote:
> > > if you had spent the time you spent on this colorful graphic on reading
> > > SUS or Posix about what sched_yield() means, you would actually have
> > > learned something. sched_yield() means "I'm the least important thing in
> > > the system".
> >
> > Susv2:
> >
> > DESCRIPTION
> >
> >  The sched_yield() function forces the running thread to relinquish
> >  the processor until it again becomes the head of its thread list. It
> >  takes no arguments.
> >
> >
> > Aka "I skip the rest of my turn, try the others again once", not "I'm
> > unimportant" nor "please rerun me immediatly".
> >
> > What is it with you people wanting to make sched_yield() unusable for
> > anything that makes sense?
>
>Have to agree, I have a context switching benchmark which uses a spinlock
>in shared memory for do-it-yourself gating, and it wants sched_yeild() to
>be useful on uni. The SuS is pretty clear about this, the useful behaviour
>is also the required behaviour, why are people resisting doing it that
>way?

It can be argued that the current implementation does exactly what SuS 
describes.  The thread's list can be considered to be the sum of the active 
queue and the expired queue.  Merely rotating the active queue and 
scheduling away excludes the yielding thread's equally important expired 
peers from participation in the game.  Furthermore, if you are the only 
thread left in the active array, (you are at the head obviously), and all 
of your peers are currently expired, yielding would become meaningless... 
the thing you're trying to yield (the remainder of your slice) sticks to you.

Having said that, it can also be argued that we are violating the SuS 
description in that yielding the remainder of your slice yields to all 
threads in all lists, not only it's list.  What makes more sense to me than 
the current implementation is to rotate the entire peer queue when a thread 
expires... ie pull in the head of the expired queue into the tail of the 
active queue at the same time so you always have a player if one 
exists.  (you'd have to select queues based on used cpu time to make that 
work right though)

That would still suck rocks for mutex usage... as it must with any 
implementation of sched_yield() in the presence of peer threads who are not 
playing with the mutex.  Actually, using sched_yield() makes no sense what 
so ever to me, other than what Arjan said.  It refers to yielding your 
turn, but from userland "your turn" has no determinate meaning.  There is 
exactly one case where it has a useable value, and that is  when you're the 
_only_ runnable thread... at which time it means precisely zero. (blech)

         -Mike