Date: Mon, 29 Nov 1999 12:29:18 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Nate Williams <nate@mt.sri.com>, Julian Elischer <julian@whistle.com>, Jason Evans <jasone@canonware.com>, freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <3842B7EE.F0D02992@vigrid.com> References: <19991124220406.X301@sturm.canonware.com> <Pine.BSF.4.10.9911250109290.12692-100000@current1.whistle.com> <199911291611.JAA19058@mt.sri.com> <199911291621.IAA06301@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3842B7EE.F0D02992>