From owner-freebsd-arch Mon Nov 1 7:16:25 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 2F66F14FD8 for ; Mon, 1 Nov 1999 07:16:18 -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 QAA03226 for ; Mon, 1 Nov 1999 16:16:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA73057 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 16:16:16 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id CF25114FD8 for ; Mon, 1 Nov 1999 07:15:58 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id KAA22175 for ; Mon, 1 Nov 1999 10:11:15 -0500 (EST) Reply-To: Randell Jesup To: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. References: <199910312340.QAA12893@mt.sri.com> <199911010116.SAA13482@mt.sri.com> From: Randell Jesup Date: 01 Nov 1999 11:12:25 +0000 In-Reply-To: Nate Williams's message of "Sun, 31 Oct 1999 18:16:19 -0700" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams writes: >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. Yes, absolutely. >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. Ditto. Here's one idea : I've worked on natively threaded (from the start) OS's in the past which allowed there to be thread-specific data that could be accessed with a (system) call (or structure reference) from the user level. One object-oriented OS allowed arbitrary attributes to be added to thread objects dynamically (which can be emulated in any OS that allows a single thread-specific pointer that can be fetched/set). This allowed for user-level data similar to the thread-specific data in the kernel (such as currentdir, which the (usermode) filesystem object module added to a thread when it was set). This may be significantly heavier than we'd wish, and there may be other reasons in a general-purpose open OS to not allow this (such as worrying about different accessors trying to use a single thread-specific datum - though an extensible (named or ID'd) attribute scheme solves that). I think it's moderately common in embedded OS's (which can be threads-only, with no heavyweight processes). -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message