Date: Mon, 30 Jul 2001 18:47:43 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Daniel Eischen <eischen@vigrid.com> Cc: arch@FreeBSD.ORG Subject: Re: Threads topics. Message-ID: <Pine.BSF.4.21.0107301836420.31506-100000@InterJet.elischer.org> In-Reply-To: <Pine.SUN.3.91.1010730182804.2337A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 30 Jul 2001, Daniel Eischen wrote: > On Mon, 30 Jul 2001, Julian Elischer wrote: > > On Mon, 30 Jul 2001, Daniel Eischen wrote: > > > 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 :-) > > Blocked threads will be put in a per-KSE queue of their own. > Having a different KSE handle the unblocking of a thread would > probably require that the thread be removed from the other > KSEs blocked queue as well as insertion into its run queue. > We could probably use the same per-KSE lock to protect both > run and blocked (and any other) queues though. Why not keep teh blocked threads on a common queue? (theoretically only a RUNNING thread is associated with a KSE in the kernel.. a blocked KSE has a point er to teh KSE it WAS on, but I'm treating that as just a hint.. what advantage do you have in keeping a per-KSE list of blocked threads? I guess I could report them only on the mailbox they came in on, but then that would lead to a thread being reported as 'back and runnable" and yet teh UTS wouldn;t know about it until THAT PARTICULAR kse/UTS ran again. It is concievable that it may be preferable to run this thread before another that is runnable on onother KSE, except that the UTS instance for that KSE doesn't know that it is available.. > > > 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? > > For the most part, yes, though you did write: > > > I have not coded the userland boundary crossing stuff yet, > > so at this stage there can only be as many threads as there are KSEs > > and the mapping is permanent. syscalls return directly instead > ^Blocking ? > > of producing an upcall to the UTS. > > I assume syscalls that don't block will always return directly > to the UTS (unless other UTS notifications are needed). A syscall that does not block may still result in a UTS upcall upon return if it wants to report that it also completed 4 other previously blocked syscalls. (It is possible that you may not want the system to make use of the chance to complete those syscalls, but rather to wait until a context switch or something. To me it makes sense to allow the kernel to say, "Hey while you're down here, I have 4 unblocked syscalls I think you should complete so that we can free up their resources" In this situation, even a call to getpid() might result in an upcall so that the UTS can decide which of the 5 threads is more urgent to complete. If you do NOT want this to happpen that would be possible but probably not the default behaviour that I'll implement. I think I'll make several of these decisions 'tunable per process' so you can decide how you want it to behave. > > -- > Dan Eischen > 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?Pine.BSF.4.21.0107301836420.31506-100000>