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 5:15:57 pm
List:org.freebsd.freebsd-arch

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.

What this means is that if one thread does a read() and blocks, the other threads don't all block.

maybe I should reword it to: "Inability of one thread to unwittingly block another thread during normal operations" ?

How about the abilty for multiple threads to execute at the same time? :)

The double negative implies that we would not add functionality that might be desired.

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).

Well they can see all the other stacks, they just don't use them as the stack. How would you better word that?

The resources are *all* shared (not just file resources), but each thread has it's own thread-specific stack.

Richard seaman's work is available. it can be used prety much without change.. Do we want to do that?

Who's we white-man? (That's a very American joke for our international readers). I'd like to here from the 'kernel architects', who have been completely silent on the topic of kernel threads up til this point. (And not just in the context of this discussion, they've been mostly silent for months, if not years on this topic, except to say that they don't like Richard's solution..)

Another thing I'd like to add to the requirements list is that the threads use 'standard' threading mechanisms for safety, such as mutex/semaphore, etc.., which should exist in the kernel as well.

This is inline with the Posix stuff, and rather than invent our 'own' new kind of data structure, I'd like to stick with known solutions that work and everyone for the most part understands.

Howeer, that requirement may be more detailed oriented than what you are looking for now.

Nate

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message