atom feed46 messages in org.freebsd.freebsd-archRe: Threads models and FreeBSD.
FromSent OnAttachments
Julian ElischerOct 31, 1999 11:57 am 
Julian ElischerOct 31, 1999 1:15 pm 
Kris KennawayOct 31, 1999 2:00 pm 
Amancio HastyOct 31, 1999 2:11 pm 
Julian ElischerOct 31, 1999 2:38 pm 
Kris KennawayOct 31, 1999 3:09 pm 
Nate WilliamsOct 31, 1999 3:40 pm 
Daniel EischenOct 31, 1999 3:43 pm 
Daniel EischenOct 31, 1999 3:53 pm 
Daniel C. SobralOct 31, 1999 4:48 pm 
Nate WilliamsOct 31, 1999 4:54 pm 
Julian ElischerOct 31, 1999 5:08 pm 
Peter JeremyOct 31, 1999 5:15 pm 
Nate WilliamsOct 31, 1999 5:15 pm 
Julian ElischerOct 31, 1999 5:41 pm 
Julian ElischerOct 31, 1999 5:49 pm 
Julian ElischerOct 31, 1999 6:16 pm 
Nate WilliamsOct 31, 1999 6:19 pm 
Nate WilliamsOct 31, 1999 6:20 pm 
Amancio HastyOct 31, 1999 6:31 pm 
Julian ElischerOct 31, 1999 6:44 pm 
Daniel EischenOct 31, 1999 7:01 pm 
Nate WilliamsOct 31, 1999 7:02 pm 
Daniel EischenOct 31, 1999 7:14 pm 
Daniel EischenOct 31, 1999 7:16 pm 
Daniel EischenOct 31, 1999 7:46 pm 
Nate WilliamsOct 31, 1999 8:12 pm 
Daniel EischenOct 31, 1999 8:53 pm 
Marcel MoolenaarNov 1, 1999 1:56 am 
Randell JesupNov 1, 1999 3:12 am 
Nate WilliamsNov 1, 1999 7:28 am 
Justin T. GibbsNov 1, 1999 9:05 am 
Nate WilliamsNov 1, 1999 11:07 am 
Justin T. GibbsNov 1, 1999 11:14 am 
Peter DufaultNov 1, 1999 11:36 am 
Daniel EischenNov 1, 1999 11:54 am 
Nate WilliamsNov 1, 1999 12:01 pm 
Nate WilliamsNov 1, 1999 12:02 pm 
Nate WilliamsNov 1, 1999 12:16 pm 
Daniel EischenNov 1, 1999 12:36 pm 
Daniel EischenNov 1, 1999 12:52 pm 
Nate WilliamsNov 1, 1999 12:59 pm 
Peter DufaultNov 1, 1999 1:04 pm 
Julian ElischerNov 1, 1999 1:18 pm 
Peter DufaultNov 1, 1999 1:22 pm 
Jacques VidrineNov 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