From owner-freebsd-arch Sun Oct 31 15:44:59 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 71BC715060 for ; Sun, 31 Oct 1999 15:44:45 -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 AAA22685 for ; Mon, 1 Nov 1999 00:44:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA67928 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 00:44:42 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id C22B614D93 for ; Sun, 31 Oct 1999 15:40:33 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id QAA06808; Sun, 31 Oct 1999 16:40:28 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA12893; Sun, 31 Oct 1999 16:40:27 -0700 Date: Sun, 31 Oct 1999 16:40:27 -0700 Message-Id: <199910312340.QAA12893@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ------------ 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 majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message