Date: Wed, 24 Nov 1999 12:20:52 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: Daniel Eischen <eischen@vigrid.com>, Matthew Dillon <dillon@apollo.backplane.com>, "Daniel C. Sobral" <dcs@newsguy.com>, freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <Pine.BSF.4.10.9911241207100.11412-100000@current1.whistle.com> In-Reply-To: <199911241957.OAA42011@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Nov 1999, Louis A. Mamakos wrote: > > Wow, so this has turned way too complicated. I confess to having the same > basic questions as Matt; why all this complexity? I think the answer is > that there's a belief that having the kernel context switch between threads > is too expensive, thus the desire to multiplex "user" threads on to fewer > "kernel scheduled" threads. This is not just a 'belief'. This is known. The work done by SUN on this and the work done by other people in the field (e.g. CMA MACH project and the much referenced Scheduler activations paper) ALL show the same thing. The optimal threading system is a hybrid. > > To answer your question: I think the question you're asking doesn't make > any sense. I think Matt was proposing that there's simply a kernel > thread context that exists for each and every "user" thread that's active > in the application. Today, there's only one of these that's intimately > associated with the process context (contains MMU/VM cntext, file descriptors, > etc.) There can be thousandds of user threads, do we want a kernel thread for each one? > > > I think we want to avoid having the kernel know too much about each > > thread. It is something that is more easily handled in the threads > > library. > > Why? If someone has done measurements comparing the different approaches, > and show that there's too much "overhead", then that's great. But it > appears that there's a considerable price to be paid in additional complexity > by sticking a user-mode thread library with it. For measurements I direct you to the "Scheduler Activations" paper by Anderson et al. (referenced early in this thread) If it's done right (and has kernel support) the user land scheduler is relatively simple. > > I ask simply because in my prior experiences with multi-threaded operating > systems, there was no such thread multiplexing happening in user space. > Certain my NeXTSTEP based system, running on a crummy 25MHz 68040 didn't > die from the "overhead". Based on Mach2.5 I know that Mach 2.5 had two threading models available. but th ekernel model was not very suitable for very large numbers of threads.. it was great for the kind of app that makes 4 threads. Not great for the kind that makes 1000. > > And previously to that, on old UNIVAC 1100 series mainframes, there > certainly wasn't any such thing going on. Their idea of "lightweight" > threads (they called them "activities") had a reduced register set to > save on context switching overhead. And they had compiler support from memory. > > Wouldn't you have minimal support for non-multiplexed threads first? For > many applications with just a handful of threads, the "overhead" issue > probably isn't even noticable. We already have that.. try the Linuxthreads port. Works great for that class of app that works great on it. :-) > > And I just hate to think of the crocks that debuggers will need to have to > be aware of this thread multiplexing going on in user space. That is a worry certainly. But it was solved for Solaris > > louie > > > > > 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.BSF.4.10.9911241207100.11412-100000>