Mark Kettenis wrote:
> So here is a diff that keeps yield() the same and adds the code in the
> sched_yield(2) implementation instead.  It also changes the logic that
> picks the priority to walk the complete threads listand pick the
> highest priotity of all the threads.  That should be enough to make
> sure the calling thread is scheduled behind all other threads from the
> same process.  That does require us to grab the kernel lock though.
> So this removes NOLOCK from sched_yield(2).  I don't think that is a
> big issue.

this does sound a little better. in theory we should be gifting priority to
the thread with the lock, but if we don't know who... more of this lock
business needs to go kernel side i suspect. still, maybe we can do the opposite
and raise other threads to this thread's priority?

Reply via email to