From owner-freebsd-hackers@FreeBSD.ORG  Thu Jan 21 13:18:25 2010
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
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 <davidxu@freebsd.org>
User-Agent: Thunderbird 2.0.0.21 (X11/20090522)
MIME-Version: 1.0
To: Bernard van Gastel <bvgastel@bitpowder.com>
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?= <des@des.no>,
	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
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=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.