kthreads and sched_relinquish

[Andrew Brampton]

2009/5/8 Ryan Stone <rysto32 at gmail.com>:
> Your kernel thread likely has a higher priority than userspace threads.
>
> Ryan Stone
>

Thanks for your reply Ryan.

So that I understand this correctly, if I had two kernel threads, one
with a high priority, and one with a low priority, and both are
PRI_TIMESHARE, then the high priority thread will run uninterrupted
until it sleeps? Or is it that kernel threads trumps userspace
threads?

>From my experience in userspace, all threads will get a chance to run,
even if there is a higher priority thread ready to run.

The exact problem I am having is that this code (written by someone
else) has implemented their own spin locks (which of course does not
sleep), so when the lower priority user thread obtains the lock, and
higher priority thread sometimes gets rescheduled before the user
thread has released the lock. Now the high priority thread spins
forever waiting for it to be released, which doesn't seem to give the
lower thread a chance. Of course the correct solution to this is to
remove these custom built spin locks and start to use the locking
mechanisms provided by FreeBSD. While I've started to do that, I
wanted to explore this more for my general understanding.

thanks
Andrew