Date: Wed, 24 Nov 1999 22:04:07 -0800 From: Jason Evans <jasone@canonware.com> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: Julian Elischer <julian@whistle.com>, freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991124220406.X301@sturm.canonware.com> In-Reply-To: <383BF031.B52BC41F@vigrid.com>; from eischen@vigrid.com on Wed, Nov 24, 1999 at 09:03:29AM -0500 References: <Pine.BSF.4.10.9911232348550.11412-100000@current1.whistle.com> <383BF031.B52BC41F@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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?19991124220406.X301>