Date: Thu, 21 Jan 2010 21:18:21 +0800
From: David Xu <davidxu@freebsd.org>
To: Bernard van Gastel <bvgastel@bitpowder.com>
Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, freebsd-hackers@freebsd.org
Subject: Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy
Message-ID: <4B58541D.1030200@freebsd.org>
In-Reply-To: <72CE899C-5941-4659-B922-DC65BB0CE67D@bitpowder.com>
References: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> <86hbqifip8.fsf@ds4.des.no> <72CE899C-5941-4659-B922-DC65BB0CE67D@bitpowder.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B58541D.1030200>