From owner-freebsd-hackers@FreeBSD.ORG Sat May 24 08:43:18 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEA2E37B401 for ; Sat, 24 May 2003 08:43:18 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CDAF43F93 for ; Sat, 24 May 2003 08:43:18 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h4OFh6wQ001958; Sat, 24 May 2003 11:43:06 -0400 (EDT) Received: from localhost (eischen@localhost)h4OFh5tV001954; Sat, 24 May 2003 11:43:05 -0400 (EDT) Date: Sat, 24 May 2003 11:43:05 -0400 (EDT) From: Daniel Eischen To: Terry Lambert In-Reply-To: <3ECF4149.EDCDD1B6@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: Dan Nelson cc: Julian Elischer Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2003 15:43:19 -0000 On Sat, 24 May 2003, Terry Lambert wrote: > Daniel Eischen wrote: > > On Fri, 23 May 2003, Terry Lambert wrote: > > > I'm rereading it, but I don't see that interpretation. > > > > > > I guess if both you and Julian both called me on it, I must > > > have misexpressed myself, but I currently don't understand > > > how. 8-|. > > > > I think it was the part about "a single CPU system with > > PTHREAD_SCOPE_PROCESS (the default) can still get itself > > blocked in the kernel by a single blocking call" without > > mentioning that it won't block other scope process > > threads from being run. > > OK... this I don't get. If the scope is process, and you > are implementing M:N, and N == 1, my understanding of the > code is that it will block exactly the same as libc_r. If > it won't (and I'm prepared to believe this), then I'd like > to know "why not?"; it should be that there is a single > scheduling object, no? It will not behave the same as libc_r. When a thread blocks in the kernel, the kernel issues an upcall to the library (on the same KSE) and the library chooses another thread and runs it. And so on, and so on, ... When threads unblock in the kernel, upcalls are also made to notify the library that those threads can be resumed. Unlike libc_r, just because a thread blocks in the kernel doesn't mean that the library won't be able to run other threads. This is the KSE system's raison d'etre. I was pretty sure you knew how all this worked... It makes me think we're talking about different things. kse(2) has some good stuff in it. > Reading the code, I don't get that there will be the ability > to do multiple returns. Is it that a KSEG is intended to > represent a quantum? If so, I've just had an epiphany as to No, the KSE has the quantum. The KSEG has the _kernel_ priority. > why you would want KSEG's at all in the first place (I've > never agreed with Julian on KSEG's, since the earliest days, > and I've only reluctantly accepted their necessity as an > artifact of scheduling priority differences for a strictest > compliance with POSIX mandated semantics -- hence my defense > of them to Jeff when he wanted to change the kernel code to > make them semi-impossible). I didn't really see the need for them either, but it is a way to have a thread group with multiple KSEs and the same kernel priority... -- Dan Eischen