Date: Thu, 11 Nov 1999 12:49:41 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Michael Schuster - TSC SunOS Germany <michael.schuster@germany.sun.com> Cc: "freebsd-arch@FreeBSD.ORG" <freebsd-arch@freebsd.org> Subject: Re: Threads goals and implementation Message-ID: <Pine.SUN.3.91.991111122739.24392A-100000@pcnet1.pcnet.com> In-Reply-To: <382ABB1A.CB959F01@germany.sun.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Nov 1999, Michael Schuster - TSC SunOS Germany wrote:
> > 5/ All threads in a process share the same system resources.
>
> IMO, this is a contradiction to 13/ and 9/
Perhaps 5 and 13 should be combined into one.
> > 6/ (contentious) Multiple theads should be bound to within the resource
> > limits of the single process (see also 13)
>
> This is implied by 5/ (I see resource limits as "resource" as well -
> "meta" resource, if you will).
OK
> > 9/ There exists a set of primatives that allow threads to influence the
> > in-process scheduling between themselves.
> > 9A/ e.g. 'per thread' Thread scheduling classes.
>
> scheduling class is an attribute of a thread, therefore a resource ->
> ergo contradiction to 5/ & 6/
This doesn't have to imply scheduling across all threads in the system.
It does state "in-process" scheduling, so I don't think that 9A is
meant to include system scheduling classes.
> > 10/ Quick access to curthread and thread specific data.
>
> see my suggestion to 5/ below; otherwise, this belongs to implementation
> issues ("quick access").
>
> > 11/ A method to ask a thread blocked in the kernel to wake up and back
> > out (similar to present 'signals').
> >
> > 12/ Processorr affinity for threads.
> >
> > 13/ Ability to create thread groups that can be assigned separate system
> > resource limits (e.g. priority, quantum).
>
> see my comment to 6/
>
> my suggestion:
>
> 5/ All threads in a process share the same resources by default with
> the following possible exceptions
> 5a/ the (limits for) the following resources can be set on a
> per-thread basis: priority, quantum, scheduling class.. (your favourite
> here)
> 5b/ thread-specific data such as curthread, thread stack, etc.
>
> and do away with 6/, 9/, 10/ and 13/
Makes sense to me, though I think that "quick access to TSD and current
thread" is a goal.
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.SUN.3.91.991111122739.24392A-100000>