From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 21 13:18:25 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from alona.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 689B11065672; Thu, 21 Jan 2010 13:18:24 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <4B58541D.1030200@freebsd.org> Date: Thu, 21 Jan 2010 21:18:21 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.21 (X11/20090522) MIME-Version: 1.0 To: Bernard van Gastel References: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> <86hbqifip8.fsf@ds4.des.no> <72CE899C-5941-4659-B922-DC65BB0CE67D@bitpowder.com> In-Reply-To: <72CE899C-5941-4659-B922-DC65BB0CE67D@bitpowder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-hackers@freebsd.org Subject: Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 13:18:25 -0000 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.