Date: Sun, 12 Dec 1999 07:59:23 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Julian Elischer <julian@whistle.com> Cc: arch@freebsd.org Subject: Re: Recent face to face threads talks. Message-ID: <38539C2B.9632089A@vigrid.com> References: <Pine.BSF.4.10.9912112354520.26823-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > > I promissed various people that I would report back what was discussed. Thanks! > We then discussed the ideas involved in a 'SA-style' approach. The > discussion was largely spent in getting everyone to understand the same > concepts in the same ways, and a lot of it was spent in working out > what subset of the SA style of things might be a good first step. > > A lot of time was spent discussing the mechanisms by which the UTS > received upcalls and how KSE's would resume. It was agreed that > thread classes could be implemented by a structure half way between a > process and a KSE on the linkage scale of things, that would own KSEs > and which would be scheduled onto processors. This basically corresponds > to what I've been calling a "subproc". In our diagrams it was designapted > "Q" as P was already taken (for Proc). This was actually an apt name as > this structure si what is put in the run queue. It was also agreed that to > start off this would be a virtual structure an it would be part of the > "proc" struct for the first revisions. Wouldn't this be akin to what other systems call a kernel thread or LWP? And could we use the same "Q" in our kernel for async I/O or interrupt threads? It could easily be attached or detached from a user space. It is important that this "Q" be able to have it's own resources though, and not necessarily be tied to a procs resources. > > KSE's would be on the sleep queues and Q's are on the run queues when > they have 1 or more KSE runnable. Where the User thread state was stored > during a syscall was discussed but I think this needs to be discussed > more. The discision was that we'd try do this without a new syscall > interface (except for one or two new syscalls (like the upcall > registration). Yes, we can pass the trapframe/context of a preempted or unblocked thread out to the upcall handler and not have to use a different call-gate. One advantage of another call-gate could be faster access to the unblocked thread. In order for the UTS to locate an unblocked thread from the information provided in the upcall, the UTS has to walk the unblocked thread list looking for the KSE ID. If you use another syscall-gate and provide the address of an IOCB, the address of the IOCB can be given to the blocked upcall handler. The UTS can then place the pointer to the thread struct in the IOCB. When the thread unblocks, the address of the IOCB is provided to the upcall handler and the UTS can just dereference it to find the thread struct. Dan Eischen eischen@vigrid.com 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?38539C2B.9632089A>