lkml.org 
[lkml]   [1998]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Thread implementations...


On Thu, 18 Jun 1998, David S. Miller wrote:

> Date: Thu, 18 Jun 1998 11:37:28 -0700 (PDT)
> From: Dean Gaudet <dgaudet-list-linux-kernel@arctic.org>
>
> [ My commented is not directed to Dean or anyone in particular,
> there were just some things I wanted to state in general wrt.
> to the issues raised here. ]
>
> Even with the debugging problems solved, linuxthreads are heavier
> than solaris pthreads or NT fibers. Both of those use a
> multiplexed user-level and kernel-level threading system which
> results in fewer kernel context switches. In userland a "context
> switch" is just a function call. But we'll see this solved with
> Netscape's NSPR which was released with mozilla -- it provides a
> multiplexed threading model (that particular model isn't ported to
> linux yet).
>
> Making threads under Linux not be multiplexed at the user side was a
> conscious design decision. Doing it half in user half in kernel (and
> this is the distinction being mentioned when Solaris nomenclature
> speaks of kernel bound and non-kernel bound threads) leads to enormous
> levels of complexity for fundamental things such a signal handling.

Sure. If you need signals that sucks. This makes pthreads really hard to
split up like this, and I can totally see why linuxthreads is the way it
is.

But something like NSPR which requires folks to write in a dialect that is
portable between unix and NT (and still access performance features on
both) doesn't have signals... because asynchronous signalling leads to far
too many race conditions and other crap, it's not even considered good
programming practice these days. I don't miss it at all. NSPR gives me
primitives like PR_Send() which writes data, with a timeout.... which
nails the main thing I would use signals for in posix -- for timeouts.

(For reference NSPR on linux defaults to single process, multiplexed via
poll/select. It can be compiled to use pthreads directly, which also
works on linux. It has a hybrid mode that hasn't been ported to linux
yet.)

> One thing to keep in mind when people start howling "xxx OS allows
> such and such feature and Linux still does not yet, why is it so
> limited etc.???" Go do a little research, and find out what the cost
> of 10k file descriptors capability under NT is for processes which
> don't use nearly that many.
>
> I know, without actually being able to look at how NT does it, it's
> hard to say for sure. But I bet low end processes pay a bit of a
> price so these high end programs can have the facility.

I'm not sure. Did you see my extended file handles proposal? I carefully
avoided O(n) crap, I think it can be done O(1) for everything but process
destruction (where you have to scan the open descriptors). And the stuff
I was proposing is close to what NT provides. But of course it's not
POSIX :)

Briefly, an extended file handle is a global index, all processes get
handles out of this single space. To implement access rights you place an
extra field in each file structure, call it file_access_right. Each
process also has a file_access_right, they have to compare equal for the
handle's use to be permitted. exec() causes a new file_access_right to be
selected. fork() uses the same file_access_right (to set up exec),
clone() uses the same file_access_right.

This is essentially what NT provides. They don't have fork -- when you
create a process you explicitly decide which handles will be passed into
the new process... and they're given new addresses in the new process. To
do that with my scheme you first need to dup an extended fh into a regular
handle. NT does that "behind the scenes".

> Unix multiplexing facilities -- select and poll -- are wake-all
> primitives. When something happens, everything waiting is awakened
> and immediately starts fighting for something to do. What a waste.
> They make a lot of sense for processes though. On NT completion
> ports provide wake-one semantics... which are perfect for threads.
>
> Yes, this does in fact suck. However, the path to go down is not to
> expect the way select/poll work to change, rather look at other
> existing facilities or invent new ones which solve this problem.
> Too much user code exists which depends upon the wake-all semantics,
> so the only person to blame is whoever designed the behaviors of these
> unix operations to begin with ;-)

Right, I've said before that I don't care what the facility looks like, as
long as it provides wake-one :)

Dean



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.341 / U:1.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site