Bernard van Gastel wrote:
But the descheduling of threads if the mutex is not available is done by the
library. And especially the order of rescheduling of the threads (thats what
I'm interested in). Or am I missing something in the sys/kern/sched files (btw
I don't have the umtx file).
Regards,
Bernard
The libthr mutex wait-queue is FIFO in kernel, however, the decision
whether a thread
should be preempted or not is made by scheduler, when mutex owner
unlocks the
mutex, it just wakes up a waiter thread from head of the queue, if the
thread
has been blocked for enough long time, kernel scheduler may decide to
raises its
priority, and if the mutex owner has spent too much cpu time, the
scheduler may
decides to low its priority, so when the mutex owner unlocks the mutex,
preemption may happen if the waiter has higher priority, and the waiter
thread
can lock the mutex, otherwise the waiter still has to wait for some time to
gain higher thread priority. It looks like round-robin fashion, and the
round-robin
quantum is made by kernel scheduler. In theory, this has best performance,
and directly hand-off seems hurt performance drastically.
_______________________________________________
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"
