From owner-freebsd-arch Thu Nov 11 9:51:23 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 68F0D14CA2 for ; Thu, 11 Nov 1999 09:51:15 -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 SAA29697 for ; Thu, 11 Nov 1999 18:51:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA12616 for freebsd-arch@freebsd.org; Thu, 11 Nov 1999 18:51:13 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 9195D14CA2 for ; Thu, 11 Nov 1999 09:51:05 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id MAA27528; Thu, 11 Nov 1999 12:49:47 -0500 (EST) Date: Thu, 11 Nov 1999 12:49:41 -0500 (EST) From: Daniel Eischen To: Michael Schuster - TSC SunOS Germany Cc: "freebsd-arch@FreeBSD.ORG" Subject: Re: Threads goals and implementation In-Reply-To: <382ABB1A.CB959F01@germany.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 11 Nov 1999, Michael Schuster - TSC SunOS Germany wrote: > > 5/ All threads in a process share the same system resources. > > IMO, this is a contradiction to 13/ and 9/ Perhaps 5 and 13 should be combined into one. > > 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). OK > > 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/ This doesn't have to imply scheduling across all threads in the system. It does state "in-process" scheduling, so I don't think that 9A is meant to include system scheduling classes. > > 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/ Makes sense to me, though I think that "quick access to TSD and current thread" is a goal. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message