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
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. =)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message