76 messages in org.freebsd.freebsd-archRe: Threads| From | Sent On | Attachments |
|---|---|---|
| Daniel M. Eischen | Nov 20, 1999 8:12 pm | |
| Julian Elischer | Nov 20, 1999 8:30 pm | |
| Julian Elischer | Nov 20, 1999 8:37 pm | |
| Daniel M. Eischen | Nov 20, 1999 9:02 pm | |
| Nate Williams | Nov 20, 1999 9:14 pm | |
| Daniel M. Eischen | Nov 20, 1999 9:21 pm | |
| Julian Elischer | Nov 20, 1999 9:25 pm | |
| Nate Williams | Nov 20, 1999 9:27 pm | |
| Daniel M. Eischen | Nov 20, 1999 9:40 pm | |
| Julian Elischer | Nov 20, 1999 10:58 pm | |
| Daniel M. Eischen | Nov 21, 1999 5:40 am | |
| Chuck Robey | Nov 22, 1999 4:30 pm | |
| Julian Elischer | Nov 22, 1999 7:57 pm | |
| Chuck Robey | Nov 22, 1999 8:11 pm | |
| Julian Elischer | Nov 22, 1999 8:38 pm | |
| Chuck Robey | Nov 22, 1999 9:40 pm | |
| Daniel Eischen | Nov 23, 1999 4:19 am | |
| Jason Evans | Nov 23, 1999 11:30 am | |
| Daniel M. Eischen | Nov 23, 1999 1:22 pm | |
| Chuck Robey | Nov 23, 1999 9:06 pm | |
| Daniel Eischen | Nov 23, 1999 9:49 pm | |
| Julian Elischer | Nov 23, 1999 10:47 pm | |
| Julian Elischer | Nov 23, 1999 11:33 pm | |
| Julian Elischer | Nov 23, 1999 11:46 pm | |
| Julian Elischer | Nov 24, 1999 2:03 am | |
| Daniel C. Sobral | Nov 24, 1999 3:19 am | |
| Daniel C. Sobral | Nov 24, 1999 3:51 am | |
| Daniel M. Eischen | Nov 24, 1999 6:03 am | |
| Richard Seaman, Jr. | Nov 24, 1999 6:33 am | |
| Matthew Dillon | Nov 24, 1999 10:35 am | |
| Daniel Eischen | Nov 24, 1999 11:02 am | |
| Matthew Dillon | Nov 24, 1999 11:05 am | |
| Anthony Kimball | Nov 24, 1999 11:25 am | |
| Daniel Eischen | Nov 24, 1999 11:28 am | |
| Matthew Dillon | Nov 24, 1999 11:41 am | |
| Matthew Dillon | Nov 24, 1999 11:47 am | |
| Julian Elischer | Nov 24, 1999 11:54 am | |
| Louis A. Mamakos | Nov 24, 1999 11:57 am | |
| Matthew Dillon | Nov 24, 1999 12:00 pm | |
| Julian Elischer | Nov 24, 1999 12:20 pm | |
| Anthony Kimball | Nov 24, 1999 12:47 pm | |
| Doug Rabson | Nov 24, 1999 2:05 pm | |
| Jason Evans | Nov 24, 1999 2:16 pm | |
| Julian Elischer | Nov 24, 1999 2:28 pm | |
| Julian Elischer | Nov 24, 1999 2:40 pm | |
| Richard Seaman, Jr. | Nov 24, 1999 3:39 pm | |
| Jason Evans | Nov 24, 1999 9:24 pm | |
| Jason Evans | Nov 24, 1999 10:03 pm | |
| Julian Elischer | Nov 25, 1999 1:08 am | |
| Julian Elischer | Nov 25, 1999 1:33 am | |
| Daniel M. Eischen | Nov 25, 1999 3:08 am | |
| Doug Rabson | Nov 26, 1999 3:01 am | |
| Jordan K. Hubbard | Nov 26, 1999 10:33 am | |
| Doug Rabson | Nov 26, 1999 12:15 pm | |
| Matthew Dillon | Nov 27, 1999 7:38 pm | |
| Arun Sharma | Nov 27, 1999 8:57 pm | |
| Matthew Dillon | Nov 28, 1999 8:41 am | |
| Arun Sharma | Nov 28, 1999 10:25 am | |
| Matthew Dillon | Nov 28, 1999 5:06 pm | |
| Nate Williams | Nov 29, 1999 8:10 am | |
| Matthew Dillon | Nov 29, 1999 8:21 am | |
| Nate Williams | Nov 29, 1999 8:29 am | |
| Matthew Dillon | Nov 29, 1999 9:05 am | |
| Matthew Dillon | Nov 29, 1999 9:19 am | |
| Daniel M. Eischen | Nov 29, 1999 9:28 am | |
| Nate Williams | Nov 29, 1999 10:29 am | |
| Julian Elischer | Nov 29, 1999 11:23 am | |
| Nate Williams | Nov 29, 1999 1:39 pm | |
| Chuck Robey | Nov 29, 1999 6:06 pm | |
| Daniel M. Eischen | Nov 29, 1999 7:46 pm | |
| Chuck Robey | Nov 29, 1999 9:01 pm | |
| Julian Elischer | Nov 29, 1999 9:34 pm | |
| Chuck Robey | Nov 29, 1999 10:09 pm | |
| Daniel M. Eischen | Nov 30, 1999 4:02 am | |
| Jason Evans | Nov 30, 1999 2:25 pm | |
| Julian Elischer | Nov 30, 1999 2:42 pm |
| Subject: | Re: Threads | |
|---|---|---|
| From: | Jason Evans (jas...@canonware.com) | |
| Date: | Nov 24, 1999 10:03:45 pm | |
| List: | org.freebsd.freebsd-arch | |
On Wed, Nov 24, 1999 at 09:03:29AM -0500, Daniel M. Eischen wrote:
Julian Elischer wrote:
I think nearly all syscalls can block given page faults etc. and having all syscalls potentially return via the UTS is going to mean some change in the kernel/process protocol.
I guess we just disagree on how the kernel is entered. I just don't see why we need to change the method of entering the kernel. We just want to switch to a new context (UTS) when a KSE blocks, and that can be done from within the kernel without changing the method entering the kernel.
One of the main advantages I see to adding an asnchronous call gate (ACG) rather than changing the semantics of the current syscalls is that mixing traditional and asynchronous syscalls is very easy. I don't see this benefiting the threads effort much in the final product, but it does have the advantages of:
1) Asynchronous syscalls are useable by programs other than those that use threads.
2) The ability to mix and match traditional and asynchronous syscalls should make incremental development much less painful.
Toggling the style of syscalls (traditional versus asynchronous) via some per-process flag would be possible, but it doesn't seem as clean to me, and it forfeits functionality without reducing complexity.
If a blocked syscall returns, then when it returns the UTS needs to be able to decide whether it is the most important thread to continue or not. So it can't just 'return', but has to come back via the UTS. This requires that things be considerably different. At least this is how I see it.
Right. And just because it woke up from a tsleep doesn't mean that it will eventually be able to finish and return to userland. It may encounter more tsleeps before leaving the kernel. The UTS needs to enter the kernel in order to resume the thread. And it needs a way of telling the kernel which blocked KSE to resume.
The UTS is notified that a KSE has unblocked, but it doesn't have to immediately resume it - other threads may have higher priority. I think we are in agreement here. I'm just advocating using the stack of the UTS event handler context (in the form of parameters to the event handlers) to tell the UTS that threads have blocked/unblocked in the kernel. There doesn't have to be any magic/wizardry in the system calling convention to do this. The kernel can return directly to the predefined UTS event handlers (also on a predefined stack) and totally bypass the original system call in which it entered the kernel. At some point later, the UTS resumes the (now unblocked) KSE and returns the same way it entered.
You also want the ability to inform the UTS of _more_ than just one event at a time. Several KSEs may unblock before a subprocess is run. You should be able to notify the UTS of them all at once. How does that work in your method?
This sounds similar to Solaris LWPs in that there are potentially KSEs blocked in the kernel, whereas with scheduler activations (SA), that doesn't happen under normal circumstances. It sounds to me like the disagreement between you two (Daniel and Julian) is much more significant than what decisions are made by the UTS. Daniel, you say "The UTS is notified that a KSE has unblocked ...". However, if I understand the SA way of doing things, there is no KSE associated with a blocked syscall. The syscall context has some kernel context, but there is no bonifide context, such as with Solaris's LWP model. When the syscall completes, a new activation is created for the upcall to the UTS.
That said, I disagree with the idea of the UTS having explicit control over scheduling of KSEs. I think that there should be exactly one KSE per processor (with the exception of PTHREAD_SCOPE_SYSTEM (bound) threads), and that threads should be multiplexed onto the KSEs. This lets the kernel schedule KSEs as it sees fit, and lets the UTS divide the runtime of the KSEs as it sees fit.
I think you and I are in agreement, but having trouble saying that.
I don't think you guys are in agreement, but one can hope. =)
Jason
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message