From owner-freebsd-arch Sun Oct 31 17:49:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id DAB0214C01 for ; Sun, 31 Oct 1999 17:49:51 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA28306 for ; Mon, 1 Nov 1999 02:49:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA69115 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 02:49:50 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 575CA14C01 for ; Sun, 31 Oct 1999 17:49:42 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id RAA29219; Sun, 31 Oct 1999 17:49:37 -0800 (PST) Date: Sun, 31 Oct 1999 17:49:34 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: Nate Williams Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911010116.SAA13482@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 31 Oct 1999, Nate Williams wrote: > > > > 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? > :) well that requires multiple processors.. see #2 maybe I need to make it more explicit? > > 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. ok gimme a better wording.. yours leads me to wonder if there is somethign special about the mamory a particular thread's stack is on.. (they don't share processor registers BTW, nor do they neccesarily share proccessors if they have affinity) > > > Richard seaman's work is available. it can be used prety much without > > change.. Do we want to do that? > > 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. yes, though maybe a meta-goal of 'be able to support all pthreads functtionality' is a good idea. > > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message