Date: Tue, 02 Nov 1999 12:53:22 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Jason Evans <jasone@canonware.com> Cc: Julian Elischer <julian@whistle.com>, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <381F2512.885AC9F@vigrid.com> References: <Pine.BSF.4.10.9911020044200.2283-100000@current1.whistle.com> <381ED720.5A24A02B@vigrid.com> <19991102084756.Z729@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jason Evans wrote: > > The ultimate goal of M:N thread scheduling (thread:LWP), as in OSes such as > Solaris, is to allow simultaneous execution of threads on (ideally) all the > processors in a system. That is, the goal should be M:P scheduling, > (thread:processor). As such, Solaris's LWP approach does a statistically > acceptable job of using the available processors, but from a pragmatic > point of view, it's a very complex (and high overhead) solution to the > problem. In my opinion, Solaris's solution is not ideal, and we should > strive to do better. We currently have only user based threads. A Solaris-like implementation would be much better than what we have now. Perhaps we really do need some definitions. We need more than one "schedulable entity" to be able to run simulataneously on multiple processor. > > > 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. > > I disagree with your disagreement. =) First, as explained above, I don't > think we should be talking in terms of LWPs. I needed _some_ term to mean "schedulable entity", within which a PTHREAD_SCOPE_SYSTEM thread could run. > Second, from a view external > to the kernel, to treat a single-threaded process as a second class citizen > IMO breaks the notion of process scheduling. Of course, depending on the > implementation we go with, process accounting may be difficult to do > "correctly", so some compromise may be necessary. And what about an application that forks/rforks? It becomes supreme being and that's OK ;-) 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?381F2512.885AC9F>