Date: Tue, 31 Jul 2001 00:16:11 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Julian Elischer <julian@elischer.org> Cc: arch@FreeBSD.ORG Subject: Re: Threads topics. Message-ID: <Pine.SUN.3.91.1010730233605.22487A-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0107301836420.31506-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 30 Jul 2001, Julian Elischer wrote: > On Mon, 30 Jul 2001, Daniel Eischen wrote: > > 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.. They don't have to be placed in a per-KSE queue, but in a per-KSE Group queue if that that turns out to be better due to the way unblocked notifications are made. I was originally trying to minimize the amount of contention between KSEs. > 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.. If we assume a per-KSE run queue for the moment, the only way one KSE will run a thread from another KSE is if that thread happens to be in a critical region. Threads in critical regions may hold up progress if not resumed until they leave the critical region. The only way a thread can be stopped in a critical region is if it was preempted or had a page fault. System calls will not be made while in critical regions, so threads should not block in the kernel within these regions. So if you want to differentiate between preempted and page faulted threads, and those threads blocked in the kernel (blocking syscalls), there is no reason that the notification of unblocked threads in the kernel _needs_ to made on the first runnable KSE. If a KSE has no more threads to run, it will make a call to the kernel to say "hey, I'm done until one of my blocked threads becomes unblocked". So the kernel needn't worry to much about the KSE running out of work; it will know when that happens and can send new upcall notifications at that time if it wants. Plus, when a KSE is resumed after being preempted, it always starts with an upcall -- another chance to send notifications. This is my UTS point of view anyways. I think we can handle notifications for threads on other KSEs, so do it whatever way you think is best. We can always change it later if we have to. > > 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" Yeah, that's what I meant when I wrote "(unless other UTS notifications are needed)" ;-) It's OK to perform an upcall to notify the UTS of events; I just wanted to be sure that every syscall wasn't going to return to the UTS via an upcall even if there were no notifications to be made. -- 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.SUN.3.91.1010730233605.22487A-100000>