Date: Thu, 11 Nov 1999 13:48:26 +0100 From: Michael Schuster - TSC SunOS Germany <michael.schuster@germany.sun.com> To: "freebsd-arch@FreeBSD.ORG" <freebsd-arch@freebsd.org> Subject: Re: Threads goals and implementation Message-ID: <382ABB1A.CB959F01@germany.sun.com> References: <Pine.BSF.4.10.9911101209550.15640-100000@current1.whistle.com> <382A0FC9.DDF8228F@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi all,
I guess I'm being a bit facetious (sp?) here, nevertheless:
"Daniel M. Eischen" wrote:
> --------------------------------------------------------------
>
> 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.
> 2A/ ability to tune and control the above..
>
> 3/ Just because one thread blocks, doesn't mean that
> the others can't keep running.
>
> 4/ All threads in a processs see the same address space (exactly).
>
> 5/ All threads in a process share the same system resources.
IMO, this is a contradiction to 13/ and 9/
> 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).
> 7/ Some well documeted scheme exists for handling signals and other async
> events.
>
> 8/ Exit/shutdown protocol is well defined.
>
> 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/
> 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/
regards
Michael
PS: Of course, one can always argue that this is just a question of how
you view and order information in your mind ... no contradiction here...
--
Michael Schuster / Michael.Schuster@germany.sun.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?382ABB1A.CB959F01>