From owner-freebsd-arch Mon Nov 1 0:52:51 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BF52314C1C for ; Mon, 1 Nov 1999 00:52:40 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id JAA05968 for ; Mon, 1 Nov 1999 09:52:39 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA71483 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 09:52:38 +0100 (MET) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (Postfix) with ESMTP id 5833B14C1C for ; Mon, 1 Nov 1999 00:52:00 -0800 (PST) (envelope-from michael.schuster@germany.sun.com) Received: from emuc05-home.Germany.Sun.COM ([129.157.51.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA18078 for ; Mon, 1 Nov 1999 00:51:58 -0800 (PST) Received: from germany.sun.com (hacker [129.157.167.97]) by emuc05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id JAA04170 for ; Mon, 1 Nov 1999 09:51:57 +0100 (MET) Message-ID: <381D54AF.8C292233@germany.sun.com> Date: Mon, 01 Nov 1999 09:51:59 +0100 From: Michael Schuster - TSC SunOS Germany Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: Threads goals version III References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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