From owner-freebsd-current@FreeBSD.ORG Sun Oct 29 00:27:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 3C17E16A40F; Sun, 29 Oct 2006 00:27:16 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: Paul Allen Date: Sun, 29 Oct 2006 08:27:09 +0800 User-Agent: KMail/1.8.2 References: <45425D92.8060205@elischer.org> <20061028105454.S69980@fledge.watson.org> <20061028194125.GL30707@riyal.ugcs.caltech.edu> In-Reply-To: <20061028194125.GL30707@riyal.ugcs.caltech.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610290827.10220.davidxu@freebsd.org> Cc: freebsd-current@freebsd.org, Robert Watson , Julian Elischer Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2006 00:27:16 -0000 On Sunday 29 October 2006 03:41, Paul Allen wrote: > Let us suppose that this M:N business is important, perhaps something > to consider is why and whether the kernel has so much knowledge of it. > > If I read Matt Dillon's comment closely enough, I believe his precise > recommendation was not "something like kse as Julian read it" but > rather something where this M:N component was entirely part of the > userland threading support and therefore would just go away or not > depending on which library you linked with. > > I think posix might require a global priority space though... > Yes, I think if libpthread wants to implement POSIX priority mutex and SCHED_FIFO, SCHED_RR for system scope thread, it should work out a way to unify priority for all process scope and system scope threads, it has to support it if we want to implement process-shared mutex, current we can not but other OS can, I found Solaris's M:N implementation will bind a M:N thread on a LWP once it has owned a PRIO_INHERIT or PRIO_PROTECT mutex and raise the LWP's priority, fix me if I am wrong. Solaris now favors 1:1. > Anyways it remains dubious in my mind that the kernel should allow > a user to create many processes but penalize creating threads. > > The only reason I can think of is that you expect people to be sloppy > with their threads and careful with their processes. > > Still if I am ray-tracing why should I need to make a point of picking > my thread/process balance to get around your mechanism. If fairness > is the goal why am I even allowed to do so?