From owner-freebsd-arch Mon Nov 29 8:29:44 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 C704B15300 for ; Mon, 29 Nov 1999 08:29:42 -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 RAA20932 for ; Mon, 29 Nov 1999 17:29:41 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA64598 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 17:29:40 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 80A7F15300 for ; Mon, 29 Nov 1999 08:29:31 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id JAA09194; Mon, 29 Nov 1999 09:29:26 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA19154; Mon, 29 Nov 1999 09:29:24 -0700 Date: Mon, 29 Nov 1999 09:29:24 -0700 Message-Id: <199911291629.JAA19154@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dillon Cc: Nate Williams , Julian Elischer , Jason Evans , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <199911291621.IAA06301@apollo.backplane.com> References: <19991124220406.X301@sturm.canonware.com> <199911291611.JAA19058@mt.sri.com> <199911291621.IAA06301@apollo.backplane.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :How's about we define what a KSE is, a SA is, and come up with some > :other term for a userland 'thread'? > : > :It seems that Julian is using the same term for a userland thread and a > :context that can go into the userland as a KSE, but I'm not sure. > : > :Assuming for a moment that this is the case, then is a SA a 'kernel > > 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. So far so good. However, we need to differentiate between a 'Userland' thread, and a 'kernel thread' somehow. Also, how does a Userland thread 'become' a Kernel thread? (We need a hybrid of Userland/Kernel threads in order for this to be a viable/effecient solution.) > 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. ^^ if? Can you expound on this more? Is this transferrable to another 'thread' in the kernel? If so, what is left? If not, what is the 'thing' that we are transferring across? > Process > > Our good old process. I think this is probably the *only* thing we all agree upon the definition of. :) > 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. So far so good. > 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. I think the term you are using for 'Thread' would be an SA, but I'm not sure everyone else would agree. > The KSE is a kernel abstraction and > essentially *invisible* to user mode. The Thread is a kernel abstraction > that is visible to user mode. I see KSE as being 'kernel context', and that *everytime* a 'thread' (userland) makes a system call, it gets assigned (created, whatever) a KSE. However, in order to do proper thread priorities, who determines which threads get a 'SA' in this context? There could be lots of threads vying for a SA (or kernel 'Thread') in this context, and the only entity with enough context to decide correctly is the UTS. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message