> 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.
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.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/