From owner-freebsd-arch Tue Nov 2 9:45:10 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 7564014C4A for ; Tue, 2 Nov 1999 09:45:01 -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 SAA24036 for ; Tue, 2 Nov 1999 18:44:59 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA81341 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 18:44:59 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id EC63E14BD2 for ; Tue, 2 Nov 1999 09:43:51 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id MAA01561; Tue, 2 Nov 1999 12:17:21 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id MAA44897; Tue, 2 Nov 1999 12:42:01 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <381F2268.AAF0498C@vigrid.com> Date: Tue, 02 Nov 1999 12:42:00 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) 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: > On Tue, 2 Nov 1999, Daniel M. Eischen wrote: > > > Julian Elischer wrote: > > > 6/ (contentious) multiple theads should be bound to within the resource > > > limits of the single process. > > > > Disagree. I want lightweight processes to have their own quantum > > not limited (in total) to the parent process quantum. > > Most people disagree with you on this one, so if you want what you > describe, you will have to thik of a way of decribing it as an optional > characteristic. We discussed this and the overwhelming majority decided > that a threaded program has no real scheduling advantage over a non > threaded program, oth that what it get's by teh nature of blockin gless > and being on multiple CPUs. Having said that, it is possible that you want > your threaded proggram to hog the system (the sysadmin may disagree, in > which case you must still be bound by your process limits). Should this be > the case, you should be able to specify some optional (non > default) characteristic that allows this.. If you can thinkk of a good way > of describing this, we can include it.. (but it can't be the default > behaviour as far as I can see.) An application can fork/rfork just as well as create a new thread with PTHREAD_SCOPE_SYSTEM. I really don't see what prohibiting LWPs from having their own quantum is buying us. I want to fully implement POSIX POSIX pthreads. I want to be able to create a thread with contention scope PTHREAD_SCOPE_SYSTEM and have it compete with all other system scope threads in the system for resources. I want what other OSs already have (well, at least Solaris). Maybe we should spend some more time looking at this from the other direction - what do we need from the kernel to fully implement POSIX and SSv2 pthreads? Let's not choose a threading model that prevents or makes it very difficult to implement the standard pthread interfaces. That said, if you want to prohibit PTHREAD_SCOPE_SYSTEM threads from being created without proper priveleges, I can deal with that, but I don't think it's necessary. > > > > > ------------- > > > Meta-goals > > > ----------- > > > We should keep our eyes on: > > > *) scalability > > > *) performance > > > *) ability to support features required by standards based threads. > > > *) ability to support features of those therad packages we select as > > > needed. > > > > How about [from the "scheduler activations" paper] Flexibility? > > * define 'flexibility' ? :-) I think the 4th point covers what we > need in that regard? OK, I guess 'flexibility' fits in there. > > Do you want other references? I know there are several available papers on > > Solaris multi-threading. There are also papers on locking mechanisms. > > > yes. references are good. OK, I'll dig some up. One would be the Valhalia book "UNIX Internals: The New Frontier" which does describe various threading models. It also mentions the scheduler activations paper. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message