Date: Tue, 02 Nov 1999 12:42:00 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Julian Elischer <julian@whistle.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <381F2268.AAF0498C@vigrid.com> References: <Pine.BSF.4.10.9911020810090.2283-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?381F2268.AAF0498C>