Date: Thu, 5 Dec 1996 13:19:35 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: cracauer@wavehh.hanse.de (Martin Cracauer) Cc: terry@lambert.org, cracauer@wavehh.hanse.de, julian@whistle.com, nawaz921@cs.uidaho.EDU, freebsd-hackers@freebsd.org Subject: Re: clone()/rfork()/threads (Re: Inferno for FreeBSD) Message-ID: <199612052019.NAA19820@phaeton.artisoft.com> In-Reply-To: <9612050824.AA20317@wavehh.hanse.de> from "Martin Cracauer" at Dec 5, 96 09:24:25 am
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... DEC's design ... ] > > The thread library maintains a constant pool of (up to) <n> KECs, where > > <n> is normally set by the number of physical processors in the system. > > (It may be smaller, if your process is locked into a processor set.) > > These are the "virtual processors" (VPs). The thread library schedules > > user threads on the pool of VPs, trying to keep all <n> of them busy. If > > you don't have enough user threads to keep that many VPs busy, they may > > not all get started, or VPs already running may go into the "null > > thread" loop and idle -- which returns the KEC to the kernel's pool for > > reuse. We'll get it back if we need it later. > > > > When a thread blocks in the kernel, the KEC stays in the kernel, but it > > gives us an upcall in a *new* (or recycled) KEC to replace the VP. When > > the blocking operation finishes, the kernel gives us a completion upcall > > in the original KEC. It's no longer a VP, so we just save the context > > and dismiss it. This is *EXACTLY* the *right way* to implement threading, if the intent of threads is to maximize concurrency (I happen to believe that that is the *only* good reason for a treading abstraction at all, and that there are a number of better ways to maximize concurrency on SVR4 and Solaris systems because of their limited implementations). > > The key is the distinction between "KEC" and "VP". There may be 100 KECs > > attached to a process, but, on a typical quad-CPU system, only (up to) 4 > > of them at any time are "VPs". The rest are just holding kernel context > > across some blocking operation. One critical aspect which appears to have been missed here is that the difference between a "process" and a "KEC" (I assume this stands for "Kernel Execution Context") can be completely artificial. Specifically, you could implement a process as a KEC with a user space address space mapping. If you "lazy switched" context (fundamentally, the same idea as "late binding" into multiple name spaces), then you can implement the kernel and user space mappings seperately. What this means is that a KEC consists of a kernel address space mapping, a stack, and an instruction pointer, and very little else, while a process is a KEC with a user space address mapping associated with it. This means that if you move all your copyin/out to uiomove, and your KEC for kernel tasks points to the KEC that originated the context, then you have no reason to change the user space mapping simply because you changed kernel execution context to a context not for the process whose user space context is active. This does mean some minor changes to device drivers to prevent any promiscuous access of user space memory by the device driver (so I can't make a device request that trashes your address space because the KEC that completes it has your processes address space mapping available to it). Basically, formalization of the interface for crossing protection domains to distinguish the kernel and user virtual address space. I'm *very* glad someone has implemented this as something other than just a "proof of concept" model... it validates many of the threads arguments I've made over the past several years (I had something similar running as a lab curiousity in UnixWare 2.x in 1994). We should christen this "the DEC model"... and we should use "the DEC model" for our own threads implementation. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612052019.NAA19820>