From owner-freebsd-threads@FreeBSD.ORG Fri May 16 21:55:32 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59ED8106566B; Fri, 16 May 2008 21:55:32 +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 EFF828FC15; Fri, 16 May 2008 21:55:31 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m4GLtUqw002375; Fri, 16 May 2008 17:55:30 -0400 (EDT) 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.0 (mail.netplex.net [204.213.176.10]); Fri, 16 May 2008 17:55:30 -0400 (EDT) Date: Fri, 16 May 2008 17:55:30 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Brent Casavant In-Reply-To: Message-ID: References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org> <482BF5EA.5010806@icyb.net.ua> <20080516201555.GL32532@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: David Xu , Andriy Gapon , freebsd-threads@freebsd.org Subject: Re: thread scheduling at mutex unlock X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2008 21:55:32 -0000 On Fri, 16 May 2008, Brent Casavant wrote: > So, let's get back to the original situation. What we have is a > traffic light that's allowing traffic in one direction 99% of > the time, and the other direction 1% of the time. _Of_course_ > the traffic on the 1% direction is going to encounter delays > and starvation; the traffic control mechanism is being used > incorrectly! The solution is not to replace it with a stop sign, > which admittedly makes everything more "fair", because it comes > at the incredibly high price of never allowing the free flow of > traffic in the other direction. I don't think this is really the problem - from what I understood, the lock is not held for a long amount of time without being dropped. It is just that more events are arriving and the lock is taken and dropped more often as events (objects, whatever) are added to the queue. It isn't a "take lock, process many events, add each to queue, release lock". This problem may be made more obtuse in the case of SMP. Consider two CPUs, with each thread running on a separate CPU. When one thread releases the lock, sees that it was contested, and reenters the kernel to wakeup the other thread, it immediately returns and beats the other woken thread to the mutex. Even a yield() might not help - the scheduler might want to keep the starving thread on the other CPU. I think to be fair, the contested mutex case should try to handoff the mutex, in lieu of any priority protocol that is in place for the threads or mutex. And actually, I think in order to properly implement priority mutexes, there must be a handoff. I think it would be very hard for the scheduler to solve this problem since it doesn't know the dependencies the threads have on the mutex (or any other userland resource). There are other ways to solve this in the application, something like I posted yesterday, perhaps a priority ceiling mutex with the starving thread having an elevated priority. But unfortunately, I think that only works if the application is running with superuser privileges (with libkse it will/would work without su privileges). -- DE