Date: Mon, 29 Nov 1999 09:29:24 -0700 From: Nate Williams <nate@mt.sri.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>, "Daniel M. Eischen" <eischen@vigrid.com>, freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <199911291629.JAA19154@mt.sri.com> In-Reply-To: <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> <199911291621.IAA06301@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> :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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911291629.JAA19154>