Date: Sun, 31 Oct 1999 18:16:19 -0700 From: Nate Williams <nate@mt.sri.com> To: Julian Elischer <julian@whistle.com> Cc: Nate Williams <nate@mt.sri.com>, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. Message-ID: <199911010116.SAA13482@mt.sri.com> In-Reply-To: <Pine.BSF.4.05.9910311652000.8816-100000@home.elischer.org> References: <199910312340.QAA12893@mt.sri.com> <Pine.BSF.4.05.9910311652000.8816-100000@home.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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 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?199911010116.SAA13482>