Date: Mon, 29 Nov 1999 08:21:30 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Nate Williams <nate@mt.sri.com> Cc: Julian Elischer <julian@whistle.com>, Jason Evans <jasone@canonware.com>, "Daniel M. Eischen" <eischen@vigrid.com>, freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <199911291621.IAA06301@apollo.backplane.com> References: <19991124220406.X301@sturm.canonware.com> <Pine.BSF.4.10.9911250109290.12692-100000@current1.whistle.com> <199911291611.JAA19058@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> > blocked in the kernel, whereas with scheduler activations (SA), that
:> > doesn't happen under normal circumstances.
:>
:> No, under SA KSE's block. and another KSE is generated to act as a
:> replacement. it is used to run the activation that is passed to the
:> scheduler, and this the next thread the process runs.
:
:That's not how I read the paper. I think we all might be on the 'same
:page', but I think we're all using different terminology.
:
: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.
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.
-Matt
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?199911291621.IAA06301>