Date: Mon, 01 Nov 1999 09:51:59 +0100 From: Michael Schuster - TSC SunOS Germany <michael.schuster@germany.sun.com> To: freebsd-arch@freebsd.org Subject: Re: Threads goals version III Message-ID: <381D54AF.8C292233@germany.sun.com> References: <Pine.BSF.4.05.9910311908080.8816-100000@home.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > 2/ Ability to simultaneously schedule M threads over N Processors, > and have min(M,N) threads simultaneously executing. > 2A/ ability to tune and control the above.. > > 3/ just because one thread blocks, doesn't mean that > the others can't keep running. > IMO, 3/ should be 2B/, since it's just another facet of the same thing. I'll try to give my view of the relationship of these things (has been voiced differently already, I'm just collecting): what we need: - entities that are treated as distinct by the kernel with respect to execution and scheduling (kernel threads). This is a direct requirement for simultaneous execution on seperate CPUs. - entities within a user process that can be scheduled independently from one another from the application's POV (userland threads - big surprise :-). Apart from the evidence of pthreads and other implementations, this is a requirement for clean code in many applications. - a mechanism for mapping _one_or_more_ userland threads (within the same process) to a kernel thread. Solaris (yes, I'm biased :-) uses the term lightweight process here (so, to contradict Dan, if I remember correctly, this is not the same thing). why not a 1:1 mapping of kernel threads to user threads? basically, cost (kernel memory & execution time) (guess why NT can't support hotmail ...:-) This is discussed in many papers... Scheduler activations as described in the Anderson et al. paper seem a good tool to circumvent some of the hurdles presenting themselves. In general, I think we should also define our meta-goals here (without any prioritisation yet): *) scalability *) performance *) any others? regards Michael -- Michael Schuster / Michael.Schuster@germany.sun.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?381D54AF.8C292233>