From owner-freebsd-threads@FreeBSD.ORG Sun Oct 29 03:56:13 2006 Return-Path: X-Original-To: threads@freebsd.org Delivered-To: freebsd-threads@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE9DE16A415; Sun, 29 Oct 2006 03:56:13 +0000 (UTC) (envelope-from prvs=julian=4503dd1c6@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBE0743D6D; Sun, 29 Oct 2006 03:56:08 +0000 (GMT) (envelope-from prvs=julian=4503dd1c6@elischer.org) Received: from unknown (HELO [192.168.2.5]) ([10.251.60.35]) by a50.ironport.com with ESMTP; 28 Oct 2006 20:55:59 -0700 Message-ID: <4544264F.5050703@elischer.org> Date: Sat, 28 Oct 2006 20:55:59 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: David Xu References: <200610290815.25252.davidxu@freebsd.org> In-Reply-To: <200610290815.25252.davidxu@freebsd.org> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: peter@freebsd.org, Daniel Eischen , gnn@freebsd.org, Kip Macy , threads@freebsd.org Subject: My suggested path for threading. 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: Sun, 29 Oct 2006 03:56:14 -0000 I suggest that we remove the fairness code. that will remove a lot of the complexity. then both libraries will be more independent of each other and the scheduler. libpthread will have system and process scope threads. libthr will have only system scope threads but will probably be the more efficient library for the larger set of processes, while libpthread will be more efficient for a smaller set. Given this, I suggest the following path: 1/ remove the fairness code.. I can do this in the 2nd part of next week. I will be on vacation then. 2/ When it is up to it, make libthr the default threading library. I say this because MOST threading applications are very simplistic in their use of threading and the simpler threading infrastructure for 1:1 threading allows for easier optimisation. They usually use threading for IO parallelization and in this case, 1:1 and M:N devolve to effectively the same thing except that M:N has more overhead. 1:1 is more efficient in this case. 3/ Keep libpthread around. I believe strongly that there is a class of threaded app where M:N (after optimization) can leave 1:1 in the dust. This class of program instantiates many objects, each of which has a backing thread to implement some form of active behaviour. These threads usually never go to the kernel and typically come to life from a mutex or condition variable and then go to sleep again waiting on same. I have seen a test example of this class where M:N gave an order of magnitude speed up. 4/ continue to adhere VERY STRONGLY to our current practice of making the libraries RUN_TIME COMPATIBLE. (i.e. libmap can switch between them) I strongly believe that the problems people have reported with "KSE" are not problems with M:N threading as they are not using M:N threading but problems with the complexity added to the scheduler by the fairness attempt. I believe removing this will almost certainly fix those problems and if it doesn't it will narrow the search significantly.