| From | Sent On | Attachments |
|---|---|---|
| Julian Elischer | Oct 31, 1999 11:57 am | |
| Julian Elischer | Oct 31, 1999 1:15 pm | |
| Kris Kennaway | Oct 31, 1999 2:00 pm | |
| Amancio Hasty | Oct 31, 1999 2:11 pm | |
| Julian Elischer | Oct 31, 1999 2:38 pm | |
| Kris Kennaway | Oct 31, 1999 3:09 pm | |
| Nate Williams | Oct 31, 1999 3:40 pm | |
| Daniel Eischen | Oct 31, 1999 3:43 pm | |
| Daniel Eischen | Oct 31, 1999 3:53 pm | |
| Daniel C. Sobral | Oct 31, 1999 4:48 pm | |
| Nate Williams | Oct 31, 1999 4:54 pm | |
| Julian Elischer | Oct 31, 1999 5:08 pm | |
| Peter Jeremy | Oct 31, 1999 5:15 pm | |
| Nate Williams | Oct 31, 1999 5:15 pm | |
| Julian Elischer | Oct 31, 1999 5:41 pm | |
| Julian Elischer | Oct 31, 1999 5:49 pm | |
| Julian Elischer | Oct 31, 1999 6:16 pm | |
| Nate Williams | Oct 31, 1999 6:19 pm | |
| Nate Williams | Oct 31, 1999 6:20 pm | |
| Amancio Hasty | Oct 31, 1999 6:31 pm | |
| Julian Elischer | Oct 31, 1999 6:44 pm | |
| Daniel Eischen | Oct 31, 1999 7:01 pm | |
| Nate Williams | Oct 31, 1999 7:02 pm | |
| Daniel Eischen | Oct 31, 1999 7:14 pm | |
| Daniel Eischen | Oct 31, 1999 7:16 pm | |
| Daniel Eischen | Oct 31, 1999 7:46 pm | |
| Nate Williams | Oct 31, 1999 8:12 pm | |
| Daniel Eischen | Oct 31, 1999 8:53 pm | |
| Marcel Moolenaar | Nov 1, 1999 1:56 am | |
| Randell Jesup | Nov 1, 1999 3:12 am | |
| Nate Williams | Nov 1, 1999 7:28 am | |
| Justin T. Gibbs | Nov 1, 1999 9:05 am | |
| Nate Williams | Nov 1, 1999 11:07 am | |
| Justin T. Gibbs | Nov 1, 1999 11:14 am | |
| Peter Dufault | Nov 1, 1999 11:36 am | |
| Daniel Eischen | Nov 1, 1999 11:54 am | |
| Nate Williams | Nov 1, 1999 12:01 pm | |
| Nate Williams | Nov 1, 1999 12:02 pm | |
| Nate Williams | Nov 1, 1999 12:16 pm | |
| Daniel Eischen | Nov 1, 1999 12:36 pm | |
| Daniel Eischen | Nov 1, 1999 12:52 pm | |
| Nate Williams | Nov 1, 1999 12:59 pm | |
| Peter Dufault | Nov 1, 1999 1:04 pm | |
| Julian Elischer | Nov 1, 1999 1:18 pm | |
| Peter Dufault | Nov 1, 1999 1:22 pm | |
| Jacques Vidrine | Nov 1, 1999 2:43 pm |
| Subject: | Re: Threads models and FreeBSD. | |
|---|---|---|
| From: | Nate Williams (na...@mt.sri.com) | |
| Date: | Oct 31, 1999 3:40:05 pm | |
| List: | org.freebsd.freebsd-arch | |
------------ Thread properties ----------- 1/ Multiple independent 'threads of control' within a single process at user level. The most basic quality of threads.
2/ Ability to simultaneously schedule two threads over separate Processors.
3/ Inability of one thread to block aother thread unless they are intentionally synchronising.
I think this can be dropped, since it's both confusing and almost contradictory. There is no such way to 'block' a regular process, although one can stop it in Unix, so the issue of blocking implies a blocking on something, which is allowed.
4/ All threads see the same address space (exactly).
5/ All threads share the same file resources.
All threads share all the same resources (except for thread-specific stack).
6/ (contentious) multiple theads should be bound to within the resource limits of the single process.
I'll leave that up to others if that's a good idea.
7/ Some well documeted scheme exists for handling signals and othe rasync events.
I think this is one of the 'hard problems' to solve.
8/ Exit/shutdown protocol is well defined.
Agreed.
9/ there exists a set of primatives that allow threads to influence the in-process scheduling between themselves.
Agreed, see #2.
10/ your ideas here. Note, you an also suggest that I remove an idea.
The ability for a process to have multiple threads active in the kernel (system calls) without stopping the process the threads are busy in.
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.
While I agree this 'simplistic' approach isn't as good as a N-M approach, it's certainly better than what we have now. Is anyone working on the more complex model *at all*, cause if not I'd like to see a simple kernel threading model used, cause something is better than nothing.
Nate
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message





