From owner-freebsd-arch Mon Nov 29 9:34: 9 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BA64014FB9 for ; Mon, 29 Nov 1999 09:34:00 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA21759 for ; Mon, 29 Nov 1999 18:33:58 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA64837 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 18:33:54 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id 5027614FB9 for ; Mon, 29 Nov 1999 09:33:46 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id MAA05359; Mon, 29 Nov 1999 12:27:05 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id MAA92350; Mon, 29 Nov 1999 12:29:19 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <3842B7EE.F0D02992@vigrid.com> Date: Mon, 29 Nov 1999 12:29:18 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Nate Williams , Julian Elischer , Jason Evans , freebsd-arch@freebsd.org Subject: Re: Threads References: <19991124220406.X301@sturm.canonware.com> <199911291611.JAA19058@mt.sri.com> <199911291621.IAA06301@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > The terminology I have been using, which I thought was the same as > Julian's but may not be, is: > > Thread > > Two entities. A kernel structure 'Thread' and also a similarly > named but independant user structure within the UTS. Under the current Julian/Dan proposal, there need not be a kernel structure 'Thread'. The UTS just sees cooperating subprocesses (rforks). I think this is because it's currently very easy to implement without drastically changing kernel internals. > > KSE > > A kernel scheduleable entity. I was using this to mean the > contextual information (such as a kernel stack) required for > the kernel to be able to run a thread. Not required for > runnability, only required to actually run the thread and > also held over of the thread blocks while in the kernel. > > Process > > Our good old process. > > I think I actually misspoke earlier. Runnability in the kernel scheduler > is governed by 'Thread', not 'KSE' with my idea. Only currently running > contexts require a KSE. i.e. you might have 10 runnable Threads linked > into the kernel's scheduler but if you have a two-cpu system, only 2 of > those 10 will actually be running at any given moment and require KSE's. > > With my system we change the kernel scheduling entity from a 'Process' > to a 'Thread' and a Thread can then optionally (dynamically) be assigned > a KSE as required to actually run. The KSE is a kernel abstraction and > essentially *invisible* to user mode. The Thread is a kernel abstraction > that is visible to user mode. > > With Julian's idea the kernel scheduling entity remains a 'Process', > KSE's are special cases within that process, and Threads appear to > be entirely userland entities. Personally, I'd like to see kernel threads be the scheduling entity, not processes. In this scheme, what Julian and I have called subprocesses would be called kernel threads. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message