From owner-freebsd-arch Thu Nov 11 4:48:47 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 7AAFC14D94 for ; Thu, 11 Nov 1999 04:48:44 -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 NAA25202 for ; Thu, 11 Nov 1999 13:48:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA11467 for freebsd-arch@freebsd.org; Thu, 11 Nov 1999 13:48:42 +0100 (MET) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (Postfix) with ESMTP id 534B514D94 for ; Thu, 11 Nov 1999 04:48:31 -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 EAA12493 for ; Thu, 11 Nov 1999 04:48:28 -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 NAA23509 for ; Thu, 11 Nov 1999 13:48:22 +0100 (MET) Message-ID: <382ABB1A.CB959F01@germany.sun.com> Date: Thu, 11 Nov 1999 13:48:26 +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 and implementation References: <382A0FC9.DDF8228F@vigrid.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, I guess I'm being a bit facetious (sp?) here, nevertheless: "Daniel M. Eischen" wrote: > -------------------------------------------------------------- > > 1/ Multiple independent 'threads of control' within a single process > at user level. The most basic quality of threads. > > 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. > > 4/ All threads in a processs see the same address space (exactly). > > 5/ All threads in a process share the same system resources. IMO, this is a contradiction to 13/ and 9/ > 6/ (contentious) Multiple theads should be bound to within the resource > limits of the single process (see also 13) This is implied by 5/ (I see resource limits as "resource" as well - "meta" resource, if you will). > 7/ Some well documeted scheme exists for handling signals and other async > events. > > 8/ Exit/shutdown protocol is well defined. > > 9/ There exists a set of primatives that allow threads to influence the > in-process scheduling between themselves. > 9A/ e.g. 'per thread' Thread scheduling classes. scheduling class is an attribute of a thread, therefore a resource -> ergo contradiction to 5/ & 6/ > 10/ Quick access to curthread and thread specific data. see my suggestion to 5/ below; otherwise, this belongs to implementation issues ("quick access"). > 11/ A method to ask a thread blocked in the kernel to wake up and back > out (similar to present 'signals'). > > 12/ Processorr affinity for threads. > > 13/ Ability to create thread groups that can be assigned separate system > resource limits (e.g. priority, quantum). see my comment to 6/ my suggestion: 5/ All threads in a process share the same resources by default with the following possible exceptions 5a/ the (limits for) the following resources can be set on a per-thread basis: priority, quantum, scheduling class.. (your favourite here) 5b/ thread-specific data such as curthread, thread stack, etc. and do away with 6/, 9/, 10/ and 13/ regards Michael PS: Of course, one can always argue that this is just a question of how you view and order information in your mind ... no contradiction here... -- 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