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

[Mike Galbraith <efault@gmx.de>]

At 11:52 PM 6/3/2003 -0400, Bill Davidsen wrote:
>On Thu, 29 May 2003, Mike Galbraith wrote:
>
> > 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)
>
>No, it works usefully without threads at all, with processes sharing a
>spinlock in shared memory. If the lock is closed process does a
>sched_yeild() to allow whoever has the lock to run. Yes to all comments
>WRT order of running, if you care you don't do this, clearly. But in the
>case where a process forks to a feeder and consumer it's faster than
>semaphores, signal, etc.

It can only be faster when there is no other source of competition for the 
cpu.  If there is no other competition, the current implementation won't 
hurt, because you'll switch arrays at very high speed... the queue rotation 
will be that which I described earlier.

There's only one real difference between going to sleep and waiting for a 
signal and your description of a proper yield.  Both place you at the end 
of your queue.  One immediately, the other upon wakeup.  How much "other 
stuff" is in the system determines task throughput in both cases.

>All that's needed is to put the yeild process on the end of the
>appropriate run queue and reschedule. Doing anything else results in bad
>performance and no gain to anything else.

And if either party has expired it's timeslice, who is the active task 
yielding to?  Why do you insist that those who have expired their slice 
should not be considered eligible players?  Now, let's throw a real 
monkey-wrench into the works...

What happens with your version of sched_yield() if one of your producer 
consumer pair is SCHED_RR, or worse - SCHED_FIFO [no timeslice, "turn" 
means until it blocks whether that be voluntary or not], and sched_yield() 
is the only way it can get rid of the cpu (ie it's a high priority pure cpu 
burner)?  If all you do is rotate the active queue and reschedule, you have 
just guaranteed that sched_yield() will have zero meaning.  The same exact 
thing (but less exaggerated) will happen if producer and consumer are not 
at the same dynamic priority.  You can call schedule() all you want if 
you're the highest priority runnable task... you get to keep the cpu 
whether you really want it or not.  I still say that sched_yield() makes 
zero sense for this usage.  There is only one guaranteed way to give up the 
cpu, and that is to sleep.

Using sched_yield() as a mutex is exactly the same as using a party line 
for private conversation.

         -Mike