From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 21 10:31:28 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1295D1065672 for ; Thu, 21 Jan 2010 10:31:28 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id C44FA8FC1C for ; Thu, 21 Jan 2010 10:31:27 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o0LAVNUT026044; Thu, 21 Jan 2010 05:31:23 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Thu, 21 Jan 2010 05:31:23 -0500 (EST) Date: Thu, 21 Jan 2010 05:31:23 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Bernard van Gastel In-Reply-To: <72CE899C-5941-4659-B922-DC65BB0CE67D@bitpowder.com> Message-ID: References: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> <86hbqifip8.fsf@ds4.des.no> <72CE899C-5941-4659-B922-DC65BB0CE67D@bitpowder.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Reply-To: Daniel Eischen 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 10:31:28 -0000 On Thu, 21 Jan 2010, 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). No, it's done by the kernel. Threads block on a umtx in the kernel, and they are also woken up by the kernel. The threads library does not wake up a specific thread - it just calls into the kernel to unlock the umtx and the kernel decides which thread to wake up. You should probably see src/sys/kern/kern_umtx.c. -- DE