Date: Mon, 29 Nov 1999 22:45:28 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: freebsd-arch@freebsd.org Subject: Revisitted.. Threads goals.? Message-ID: <Pine.BSF.4.10.9911292207120.7902-100000@current1.whistle.com> In-Reply-To: <Pine.BSF.4.10.9911201834440.6767-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I think this is a good time for us to re-examine some of the things that
we decided were goals.
I have somme comments I'd like to make AT THE END, but after the general
neuron frying of the last week or so it might be a good idea to look at
these again and see if any of them have changed in light of the
discussion. I have difficulty in seeing this list as exhaustive or
correct. We need someone who is very into threads to contribute.
Jason? What do yuo see as YOUR goals?
-----last version of the goals I have in my mailbox.----
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).
4A/ All threads in a process share the same system resources, except cpu
which is treated specially, and some as yet unspecified thread
specific uniqifier.
5/ A process may be able to group threads into classes that have
different system priorities. These classes can not have priorities
greater than the process itself or a child could achieve, and should
be treatable by the system as a separate child process from a
scheduling point of view (including limits).
5A/ As a result threaded processes should have no more capability to
swamp a system than a regular forking process.
6/ Some well documeted scheme exists for handling signals and other
async events.
7/ Exit/shutdown protocol is well defined.
8/ The allocation of user level threads to thread groups is opaque to the
kernel.
9/ Quick access to curthread and thread specific data.
10/ A method to ask a thread blocked in the kernel to wake up and back
out (similar to present 'signals'). (see 6, 7)
---- possible userland implementation goals-----
1/ A libpthread that can be linked with libc.
2/ Libc needs to change so that library functions and system calls
used internal to the library do not use the externally visible
cancellable equivalents.
3/ see 8 above.
-------------
Meta-goals
-------------
We should keep our eyes on:
*) scalability
*) performance
*) ability to support features required by standards based threads.
*) ability to support features of those thread packages we select as
needed.
---------------------------
COMMENTS:
Peter made a valid point which is that maybe we should figure out
a waypoint between here and there, that gives us a working but
sub-optimal threads package of the order of the linux threads package,
that can be included in 4.0
We may have 2 whole months to get that done :-(
Also, Matt Dillon has been arguing strongly that point 8 (kernel)
and point 3(user) are non goals, in fact he wants the opposite.
He also argues that making an entity that groups KSE's on a scale smaller
than the entire process is a bad idea. I disagree but we haven't
decided anyting yet. He claims 'simplicity. I think that he may be sliding
back up teh other side of th ecurve by trying to simplify more than the
goals (many of which we are inherritting from Posix via the 3rd meta-goal)
allow.
how would we move towards Peter's hope? and are there things we can do
that there is no argument about? I think that separating the proc
structure is agreed, but it is not needed for Linux threads..
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.9911292207120.7902-100000>