2009/5/8 Ryan Stone <ryst...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
