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
On Wed, Jun 04, 2003 at 09:13:43AM +0200, Mike Galbraith wrote:
> Using sched_yield() as a mutex is exactly the same as using a party line
> for private conversation.
I actually used sched_yield for the 'inverse' mutex case. One thread was
pretty much exclusively holding a mutex, but other threads sometimes try
to get through the same critical section and block on mutex_lock.
The first thread then occasionally does,
mutex_unlock()
sched_yield()
mutex_lock()
Without the sched_yield, other threads never get a chance to wake up and
grab the mutex before the mutex hogging thread is back in the critical
section.
This is ofcourse the simple explanation, this was actually part of a
wrapper around pthreads that needed to provide non-concurrent
co-routines that in specific situations could run concurrently for a bit
to do DNS lookups and such.
Not sure how different semantics affect this because I went with a
different solution a while ago.
Jan