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