Date: Tue, 02 Nov 1999 10:16:50 -0700 From: "Russell L. Carter" <rcarter@chomsky.Pinyon.ORG> To: Julian Elischer <julian@whistle.com> Cc: "Daniel M. Eischen" <eischen@vigrid.com>, freebsd-arch@freebsd.org, rcarter@pinyon.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <19991102171650.BAE8D58@chomsky.pinyon.org> In-Reply-To: Message from Julian Elischer <julian@whistle.com> of "Tue, 02 Nov 1999 08:19:19 PST." <Pine.BSF.4.10.9911020810090.2283-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry for the long inclusion, but... % % %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.) % I don't see my responses on the list, is it for committers only? If so, this will be my last contrib. I agree with Daniel. Randell Jesup <rjesup@wgate.com> writes: % While I wouldn't want you to go far out of your way, a reference %or two (or summary thereof) might help people. This one details how (multithreaded) distributed objects can be implemented so that QoS requirements can be met, it's pretty much the definitive paper so far on how these things are done. Included is a detailed analysis of threading models. However, it's 55 pages long. http://www.cs.wustl.edu/~schmidt/RT-ORB.ps.gz This one focuses in on thread QoS performance for a variety OS's, including NT, Linux, Solaris, VxWorks, and Lynx, with an implementation of the designs in the above paper: http://www.cs.wustl.edu/~schmidt/RT-OS.ps.gz Here's a paper which extracts out the threading issues from RT-ORB.ps and discusses it in 8 pages: http://www.cs.wustl.edu/~schmidt/CACM-arch.ps.gz To summarize, I have clients that are very large companies that have settled on the architecture described in these papers. Most of the new development projects for the U.S. DoD that I am familiar with incorporate some aspect of this technology in their architecture. Apparently, some telcos and financial systems are adopting as well. High performance/RT distributed objects were a fiasco until the thread capabilities began to mature, but now it is pretty well understood how to build these things given a complete thread implementation such as described in Kleiman, Shah, and Smaalders. From their book, I quote (p207-208): "There are some cases in which it is not desirable for a thread to be scheduled purely local to a process. In particular, threads that must be scheduled on a realtime basis must be prioritized and scheduled with respect to all the other threads in the system; in other words, they must have system-wide contention scope". Though I'm not sure what the problem is here, pthread_attr_setscope is defined to take either PTHREAD_SCOPE_PROCESS or PTHREAD_SCOPE_SYSTEM. Just don't give PTHREAD_SCOPE_SYSTEM capability to unpriviledged processes. Russell % % %> %> > ------------- %> > 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 % 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?19991102171650.BAE8D58>