timw@splhi.com said:
> On a uniprocessor system, a simple fallback is to just use a semaphore
> instead of a spinlock, since you can guarantee that there's no point
> in scheduling the current task until the holder of the "lock" releases
> it.
Yeah, that works. But I'm not all that interested in compiling UML
differently for UP and SMP hosts.
> Otherwise, the spin calling sched_yield() each iteration isn't too
> horrible.
This looks a lot better. For UML, if there's a thread spinning on a lock,
there has to be a runnable thread holding it, and that thread will get a
timeslice before the spinning one (assuming that the thread holding the lock
hasn't called a blocking system call, which is something that I intend to make
sure can't happen).
> > That sounds like a pretty fundamental (and abusable) mechanism.
>
> It would be if it were generally available. The implementation on
> DYNIX/ptx requires a privilege (PRIV_SCHED IIRC), to be able to use
> it.
OK, that makes sense.
Jeff
-
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/
This archive was generated by hypermail 2b29 : Thu Mar 15 2001 - 21:00:09 EST