10 messages in org.freebsd.freebsd-archRe: Threads topics.| From | Sent On | Attachments |
|---|---|---|
| Daniel Eischen | Jul 30, 2001 1:18 pm | |
| Julian Elischer | Jul 30, 2001 2:18 pm | |
| Warner Losh | Jul 30, 2001 2:20 pm | |
| Daniel Eischen | Jul 30, 2001 3:38 pm | |
| Julian Elischer | Jul 30, 2001 3:45 pm | |
| John Baldwin | Jul 30, 2001 3:47 pm | |
| Julian Elischer | Jul 30, 2001 5:33 pm | |
| Julian Elischer | Jul 30, 2001 6:47 pm | |
| Daniel Eischen | Jul 30, 2001 9:15 pm | |
| Peter Wemm | Aug 1, 2001 1:39 pm |
| Subject: | Re: Threads topics. | |
|---|---|---|
| From: | Julian Elischer (jul...@elischer.org) | |
| Date: | Jul 30, 2001 3:45:35 pm | |
| List: | org.freebsd.freebsd-arch | |
On Mon, 30 Jul 2001, Daniel Eischen wrote:
On Mon, 30 Jul 2001, Julian Elischer wrote:
Thread 2 comes ready. It also was last run on KSE-1 so it is hung off the already running KSE-1. However since the number of runnable threads is greater than the number of runnable KSEs, but less than the number of KSEs created (2) we get another KSE at random (KSE-2) and place it on the run queue.
From the UTS perspective, it may be easier to deal with unblocking of threads if notifications were only on the KSE in which the thread was running. For concurrency levels > 1 (more than 1 KSE in the KSE Group), the UTS may have 2 sets of queues -- one for each concurrency level.
If KSEs may get notifications for threads running in other KSEs, it means that there will have to be some inter-KSE locking of blocked and running thread queues. And each KSE has it's own mailbox, so it might force KSEs to fiddle with mailboxes they don't own.
no it would never have to fiddle with a mailbox that it didn't own, but it might find a thread on its "completed" list that it should put on the other run queue. If I don't do that then there will be times when I could run a thread but instead will sit idle. It is of course easy to do.. (comment out some code :-)
In the first version it will always come back on the same KSE because there is a 1:1 relationship between threads and KSEs.
I'm rewriting this stuff at the moment. I 'll make sure it can be done either way (allow or not allow a thread to change KSEs while in the kernel.)
So, did the rest of what I wrote make sense?
the important bit is writing the code to put things on the run queues in the new scheme that degenerates to exactly the current operation in a 1:1 situation.
I'm not saying we can't do it, just that we may want to postpone that for later.
-- Dan Eischen
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message