Date: Mon, 2 Jul 2001 19:40:01 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Bakul Shah <bakul@bitblocks.com> Cc: current@freebsd.org Subject: Re: RFC: Kernel thread system nomenclature. Message-ID: <Pine.BSF.4.21.0107021913550.13213-100000@InterJet.elischer.org> In-Reply-To: <200107022120.RAA06256@ajax.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Jul 2001, Bakul Shah wrote:
> Is there is an online description of what you guys decided at Usenix?
> An xfig picture would be very helpful!
[...]
I'm working on one.
>
> proc or process? Actually "domain" is more appropriate once
> you can have multiple threads sharing the same VM.
>
[...]
>
> How about just schedule or schedule set? It is a
> perfectly good noun! "control block" is just noise at this
> point :-)
>
> Seems like the old (Thoth) team concept. Can a thread
> context belong to more than one of these?
>
The thread 'carrier/slot/container' (KSE) cannot, but a user thread
may be reassigned from one to another by the Userland thread scheduler.
In the kernel a thread must return on the same one as it went in on,
but while in userland it could be switched.
>
> I am confused about #3 and #4.
#3 is a virtual processor onto which the userland can schedule threads to
run. When a syscall blocks, the virtual processor returns via an upcall
and asks for another thread.
So even with only one processor you get many parallel syscalls....
#4 is the context in the kernel of such a thread while doing a syscall,
and possibly blocked.
> Sounds to me like #3 is a
> runnable thread context and #4 is a sleeping/waiting thread
> context. A runnable thread is bound to a processor. For
> example, Given
> processes A, B & C
> processors X & Y,
> Threads A1, A2, B1 are runnable; A3, B2, C1, C2 are waiting,
> A1,A3 in one and A2 in another schedule set,
> A1 and A2 are actually running, B1 is waiting for a processor
> we have
> 3 #1 entities (A, B, C)
> 4 #2 entities ({A1,A3}, {A2}, {B1, B2}, {C1, C2})
> 3 #3 entities (A1, A2, B1)
> 4 #4 entities (A3, B2, C1, C2)
> Correct? I am not sure how actually running threads are
> distinguished from a runnable thread.
No..
we have:
3 #1 entities (A, B, C)
4 #2 entities ({A1,A3}, {A2}, {B1, B2}, {C1, C2})
7 #3 entities (A1, A2, A3, B1, B2, C1, C2)
4 #4 entities on sleep queues (A3, B2, C1, C2)
3 #4 entities actially running (A1,A2)
1 #4 entity hanging off the 'B' #2 entitiy, which is on the run queue.
These are all teh threads that are presently IN THE KERNEL.
(well, A1 and A2 might be in user space)
Since A3, B2, C1, C2 are waiting obviously there are no more
userland threads to be run in A*, B or C, or they would be running them.
(A* is process A but at a different priority)
this example is actually bad because:
1/ it doesn't show any user threads.
2/ no process has more threads than there are processors in
a scheduling group.
#4 items that are blocked are divorced from their #3 items, allowing the
#3 items to return to userspace to get more work.
#3 items are always in one of 3 states:
1/ active in userspace, awaiting a trap or fault.
2/ active in kernel space, running code from a syscall.
3/ suspended, awaiting a blocked context to be made runnable by an
interrupt or by a user signal. There may be many more #4 than there are
#3 but only #4 that are ACTUALLY RUNNING are assigned to an #3.
a #3 has a cpu resource and a #4 has the context needed to run on it.
>
> But this would confuse future hackers. Appropriate names
> really help even if it means moe editing now. I have found
> that the process of coming up with the right names frequently
> simplifies things.
That's why I'm asking :-)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0107021913550.13213-100000>