Date: Sun, 7 Nov 1999 02:45:04 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Russell L. Carter" <rcarter@chomsky.Pinyon.ORG> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <Pine.BSF.4.10.9911070237440.10573-100000@current1.whistle.com> In-Reply-To: <19991102143819.5D0F23B@chomsky.pinyon.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2 Nov 1999, Russell L. Carter wrote: > %In message <381EDBCE.FD7FBA68@vigrid.com>, "Daniel M. Eischen" writes: > % > %>> >Disagree. I want lightweight processes to have their own quantum > %>> >not limited (in total) to the parent process quantum. > %>> > %>> That would clearly kill the "lightweight" in "lightweight process"... > %> > %>That doesn't mean they each have to have the same quantum as a non-MT > %>process. > % > %That has nothing to do with it. > % > %There is not much point in making a lightweight process facility > %if the resulting processes are not lightweight. > > Then the application developer should choose libc_r threads. > > There isn't much point to doing this effort if the > pthread_*sched* functions don't actually mean much in the > global context. > > People building large scale distributed objects that > are also high performance require fine grained schedulability > of individual threads. I can provide references that demonstrate > how low level thread scheduling architecture > affect high level services. > > Solaris, HP, MVS, and Linux support this to varying degrees now. > The RT-OSs more or less do, though some fail in surprising ways. > Linux is surprisingly good. > > Put another way, cramming a process's threads into a single > scheduling quanta significantly diminishes the suitability of FreeBSD > as a platform for building high performance and/or RT CORBA apps. Let's rephrase this.. Firstly 'A single scheduling quanta' is probably a misleading statement. firstly it would be 'A group of quanta' as the process may be at a priority where it gets a lot of time and there may be only one other process with only 1 quanta allocated to it.. 99/100 is pretty close to all you can get.. secondly, I see a need to be able to effectively 'fork off a separate family of threads' that are treated as a separate scheduling entity. Thsi only makes sense at all if the threads in that group are explicitly bound to that group, and other threads cannot arbitrarily wander in and out of the group. The sum of the processing quanta for the original and the new class would be the same as a user process forking to run 2 processes in parallel, and would be limited by the same mechanisms. The second process could not increaes its priority higher than the parent, just like nice(2) at the moment. (You wuld need root priority to do that) > > Regards, > Russell > > > > %-- > %Poul-Henning Kamp FreeBSD coreteam member > %phk@FreeBSD.ORG "Real hackers run -current on their laptop." > %FreeBSD -- It will take a long time before progress goes too far! > % > % > % > % > %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 > 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.9911070237440.10573-100000>