From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 18:53:22 2007 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 CA75816A41A; Fri, 21 Dec 2007 18:53:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC9D13C46A; Fri, 21 Dec 2007 18:53:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 225455899-1834499 for multiple; Fri, 21 Dec 2007 13:35:14 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id lBLIarwR088679; Fri, 21 Dec 2007 13:37:02 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-threads@freebsd.org, Daniel Eischen Date: Fri, 21 Dec 2007 13:36:44 -0500 User-Agent: KMail/1.9.6 References: <200712210700.lBL707MZ002071@freefall.freebsd.org> <476B7476.3010509@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712211336.44996.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 21 Dec 2007 13:37:03 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5208/Fri Dec 21 12:02:14 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: David Xu Subject: Re: threads/118910: Multithreading problem X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2007 18:53:22 -0000 On Friday 21 December 2007 03:16:15 am Daniel Eischen wrote: > On Fri, 21 Dec 2007, David Xu wrote: > > > Daniel Eischen wrote: > > > >> I don't think it is as big a change as you think it is. We already > >> have several layers of priorities (interrupt, time-share, idle, ?). > >> All threads belong to these classes. As long as priority inheritence > >> works, there should be no problems. The problems seem to occur when > >> we try to inject artificial priorities into threads, like using > >> msleep(). I think we are better off just letting threads run based > >> on their own base priority and whatever their inherited priority is. > >> > > > > For test purpose, you may try to ignore thread priority parameter > > in msleep(), I didn't test this, but it does change the FreeBSD > > behavior. I don't know any side effect since I am unable to test > > all applications in the world, maybe you can start a project to hack > > it ? > > I'll take a look at trying that. I should be able to figure out > how to get msleep to ignore the priority. But I think the missing > piece is the interrupt routines - they need to create their mutexes > and CVs so that they are more like priority ceiling mutexes. Any > thread (even non-interrupt threads) that takes one of these mutexes > needs to have its priority raised as well as blocking the interrupt > (for fast interrupts anyway) until the mutex is released. One issue is that some places actually use the sleep priority for other decisions. (For example, we dont' swap out threads at PSOCK or higher.) You'd need to fix this logic in another way. Solaris also bumps the priority of threads that acquire a read lock on a rwlock to a kernel-level priority to work around lack of priority propagation for readers. An alernative to that is to bump the priority of threads that are in the kernel to a kernel-level priority on kernel-entry, but then you have to be careful about threads that are just waiting for the CPU and not a lock or other resource or all threads will effectively be scheduled at kernel-level priorities. One thing I have wanted to do as a small step is to add a sched_sleep_prio() for the msleep(9) priority (along iwth a get_sleep_prio() or some such for places that want to check PSOCK) and let the scheduler factor that into the actual priority but don't enforce that the msleep(9) arg actually sets the priority. I do think cv's don't need to have priorities. I'm not sure that mutexes for drivers need priorities as in Solaris since priority propogation should already handle that case if the mutex is needed by an ithread. -- John Baldwin