Date: Tue, 2 Nov 1999 00:59:28 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: freebsd-arch@freebsd.org Subject: Threads models and FreeBSD. (Next Step) Message-ID: <Pine.BSF.4.10.9911020044200.2283-100000@current1.whistle.com>
next in thread | raw e-mail | index | archive | help
Here is an updated version of the rather simplistic requirements for a
threads model for freeBSD.
New requirements can be added as we go along but these should give us
tomething to go on..
Now, we need to start collecting alternative implementations that might
satisfy these goals. We should gathe rinformation on these and READ teh
literature and code, before discussinghtese too much. getting into
arguments at this stage will not help the process.
We have 4 starters at this point. Note, they MAY NOT BE mutually
exclusive!
1/ The scheme we've been working towards for a while due to lack of
suggested alternatives.. rfork based processes sharing resources.
This is very similar to the Linuxthreads implementation. one kernel
schedulable entity (light process) per thread.
1A/ actually use the linuxthread code..
2/ A variant of (1) where blocking processes somehow signal a userland
action that starts another thread in another rfork'd process. I have heard
rumours that someone was looking at this. Could they own up?
3/ The much referenced paper on "Scheduler activations"
Everyone should read this paper as homework (It's referenced below)
before participating further in this disussion.
4/ Terry's schem. (similar in some ways to (3) but not the same..
TERRY's homework is to write it down.
5/ Any more schemes paple know of, can go here.
julian
[1st reposting, (with changes)]
------------------------------------
This article will be reposted again for late comers in the
discussion thread:
There are several properties of threads that make them both good and bad
programming models. John Ousterhout gave a keynote at Usenix a couple of
years ago titled "threads considered harmful", which was both ammusing and
had more that a shred of truth to it. Having said that, good thread
support is essential able to support a lot of modern programs, and is
a good way of ensuring that processes can make use of the increasing
amount of MP machinery that is available.
So what are the definitions that a thread enabled environment should
possess? This not a definative list, and before we go on to solve the
worlds threading problems, I'd like everyone to add their thoughts to this
list so that we can agree about what problems we are trying to solve.
If you are going to say "support pthreads" I'd like you to instead break
that down to what we need to have in order to support pthreads.. I want
pthreads to be a by-product (almost) of a good threading model, not the
design goal.
--------------------------------------------------------------
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.
6/ (contentious) multiple theads should be bound to within the resource
limits of the single process.
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.
10/ Quick access to curthread and thread specific data.
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.
---- 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.
-------------
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 therad packages we select as
needed.
---
refs:
http://www.freebsd.org/~deischen/p95-anderson.pdf
http://www.freebsd.org/cgi/getmsg.cgi?fetch=25000+30231+/usr/local/www/db/text/1
999/freebsd-current/19990321.freebsd-current
http://lt.tar.com/
-------------------------------------
-------------
What we have at the moment:
John Birrell's excelent work on user-level threading (libc_r), based
originally on Chris provenzo's threading code has given us quite a bit of
mileage so far, but it's starting to run out of steam with new
requirements being more certain about kernel support requirements.
It is notable that we already support Linux kernel threads on FreeBSD
better than we support a native threads model. This is because we support
the 'clone' system call through our rfork() code, and that is their basis
for threading. As is common for this group of people, we have not adopted
the Linux approach because it is considered to be 'too simplistic',
assigning a separate kernel schedulable process to run each thread.
Having said that, Amancio Hasty at one stage wrote a set of threading
primitives to allow Kafe to run on FreeBSD using this scheme of threading,
and Richard Seaman has a port of the Linuxthreads code to freeBSD at his
website, http://lt.tar.com/ . This represents a useful piece of work and
though it is presently not working on -current, hopefully this will be
fixed soon. I believe there may be problems with the new signal stuff
though I have not tested it myself.
I also reference the following email in the archives:
http://www.freebsd.org/cgi/getmsg.cgi?fetch=25000+30231+/usr/local/www/db/text/1999/freebsd-current/19990321.freebsd-current
Peter dufault also has some work on scheduling that may be slightly
relevent.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
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.9911020044200.2283-100000>