Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Nov 1999 08:47:57 -0800
From:      Jason Evans <jasone@canonware.com>
To:        "Daniel M. Eischen" <eischen@vigrid.com>
Cc:        Julian Elischer <julian@whistle.com>, freebsd-arch@freebsd.org
Subject:   Re: Threads models and FreeBSD. (Next Step)
Message-ID:  <19991102084756.Z729@sturm.canonware.com>
In-Reply-To: <381ED720.5A24A02B@vigrid.com>
References:  <Pine.BSF.4.10.9911020044200.2283-100000@current1.whistle.com> <381ED720.5A24A02B@vigrid.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 02, 1999 at 07:20:48AM -0500, 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?

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.

> > 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.  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.

Jason

Jason Evans <jasone@canonware.com>
http://www.canonware.com/~jasone
Home phone: (650) 856-8204
Work phone: (415) 808-8742
"I once knew a happy medium.  Her name was Zohar." - James Foster




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?19991102084756.Z729>