Date: Tue, 2 Nov 1999 08:19:19 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <Pine.BSF.4.10.9911020810090.2283-100000@current1.whistle.com> In-Reply-To: <381ED720.5A24A02B@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > > > Here is an updated version of the rather simplistic requirements for a > > threads model for freeBSD. > [...] > > > > 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. > > Shouldn't this be M threads over N [lightweight] Processes? well, not until we decide that we are going to HAVE LWPs. :-) this is teh really highest level requirement. > > > 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.) > > > ------------- > > 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? > > > > > refs: > > http://www.freebsd.org/~deischen/p95-anderson.pdf > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=25000+30231+/usr/local/www/db/text/1 > > 999/freebsd-current/19990321.freebsd-current > > http://lt.tar.com/ > > 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. > 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?Pine.BSF.4.10.9911020810090.2283-100000>