Date: 01 Nov 1999 11:12:25 +0000 From: Randell Jesup <rjesup@wgate.com> To: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. Message-ID: <ybug0yqh3dy.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Nate Williams's message of "Sun, 31 Oct 1999 18:16:19 -0700" References: <199910312340.QAA12893@mt.sri.com> <Pine.BSF.4.05.9910311652000.8816-100000@home.elischer.org> <199911010116.SAA13482@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams <nate@mt.sri.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybug0yqh3dy.fsf>