Pthreads originated with the community that cared about
thread-as-programming-extraction, and not
thread-as-operating-system-concept. It was stuck with a need to support the
lowest common denominator, ie,
library-threads-in-a-process-on-a-uniprocessor. No matter what else was
done, it had to have semantics that made sense in that case. (After all,
some would say, even at that time, if you want processes to share memory,
you can do that with SYSV memory ops.)
Since I do have a physics bent (my only formal training is as a mathematical
physicist, after all,) I think I'd draw a different analogy. pthreads are a
programming language abstraction, not an operating systems abstraction.
They are, ie, physical chemistry, when you keep wanting to do particle
physics. (and if you think your theory of magnetism/maxwell model holds, I
have some reading in the theory of concurrent computing to recommend -- even
'pure threads' are primitive by comparison to, say, Chandy and Misra.)
But if you want 'Right', you are in the wrong business. Operating systems
are about blurring the boundary between programming language and 'virtual
machine' abstractions and real devices. In my opinion, DMR was probably the
last person who got a shot at designing both a language and an OS at once,
and producing something economically viable, for a very long time into the
future. (There are folks at DEC who got to design both, but Modula3 is not
going to replace C/C++... and ML is a better 'Right' language, anyway.) Once
you've adopted C, you are stuck with engineering and not abstraction.
Besides, not all computers, even general purpose computers, are used for the
same thing, and it is the rare algorithm that stretchs across the entire
application domain, even in threading.
My opinion is that you will end up with a split level thread design in
Linux, simply because of the synchronization/scheduling interaction. Once
you've accepted that, you'll have to struggle with the three kinds of
thread: threads-as-programming-abstraction,
threads-as-concurrency-mechanism[with realtime overtones] and
threads-as-multiprocessing-mechanism. Based on experience with a range of
concurrency models spanning more years than I'd care to admit to, I suspect
that you'll end up with a model like variable-weight-processes (which
clone() isn't that far from, now,) with Bershad's scheduler activations or
something similar.
We're really not talking about Right/wrong or 'big ideas' and 'little
ideas.' (but i'll be glad to buy you a beer anytime you're in Mountain
View.) n:m threads versus 1:1 threads is pretty much like comparing
different superstring theories when you don't even have a good estimate of
the mass of the universe. You want a big idea: throw the process/thread
model away and do something like Arvind's dataflow machines, or design an
operating system to support declarative rather than imperative programming.
And you'll find the whole thing will be an exercise in performance tradeoffs
between threads-as-programming-language constructs and scalablility in
multiprocessor applications. (oh, and synchronization primitives are a
critical part of a thread model . . . -- that's one of the reason's Java's
is so broken.)
But it won't get really interesting until the processor count is O(64) and
the system is NUMA. ;)
marty
-----Original Message-----
From: torvalds@transmeta.com [mailto:torvalds@transmeta.com]
Sent: Sunday, August 27, 2000 10:38 PM
To: linux-kernel@vger.kernel.org
Subject: Re: SCO: "thread creation is about a thousand times faster than
In article <52C41B218DE28244B071A1B96DD474F60AD231@DC-SRVR1.dotcast.com>,
Marty Fouts <marty@dotcast.com> wrote:
>
>I'm curious: what assumptions did we have about threads 15 years ago that
>turned out to be false?
Personal opinion, and it has nothing to do with "15 years ago" vs
"today":
The pthreads approach never got to a real framework for threads as real
entities. To pthreads, a thread is a braindamaged stepchild of a
process, and cannot do anything on its own. It's this drooling messy
thing that has no life without the parent process that wipes up after
it. It has no spine.
In short, threads are not proper citizens. They are guest workers.
Expendable. Worthless. They don't have a life of their own.
Now, the notion of rfork/clone/sproc "variable-weight processes" is not
new per se. But it's an important _notion_. It basically says that
threads are _not_ the ugly drooling stepson that you really wouldn't
want to see at family re-unions.
Suddenly, with rfork/clone/sproc, a thread is not just something that
you can prod in the right direction with the cattle prod of a random
collection of POSIX routines. A thread is an Idea. A Notion.
Something worthy of a capital letter. Something you can discuss in
mixed company.
It's the difference between being useful and being Right.
It's hard to explain. If you have a bent toward physics, it's the
difference between a practical experiment and the Unified Teory of
Everything. It's the difference between Galileo saying "everything falls
at the same speed" and Newton's "F = mMG/rē".
If you're religious, it's the difference between "It was a dark and
stormy night.." vs "Let there be Light!".
If you're into computers, it's the difference between Windows ("sure, it
works much of the time, and it looks pretty") and Unix ("everything is a
process or a file").
It's like an idea: there are mundane ideas ("hey, let's go out for pizza
and a beer") and there are big ideas ("I have a dream..").
The difference? The big idea leads to something larger than itself. It
makes people think about what the meaning of life is. It gives a
_direction_ for where things are supposed to go.
In contrast, a small idea leads to other small ideas (fifteen beers
later: "I know, let's drive past the police station and moon every cop
in the city!").
Ok. I'm overdoing it. But think of rfork/clone/sproc as a way to try to
come to grips with what it really means to be a thread. Be one with the
thread. Grok the threadedness - so that you can understand what is wrong
and what is right _without_ having to count every comma in a standards
draft that is 473 pages long.
In short, "pthreads" is a rough approximation of the theory of
magnetism. While rfork/clone/sproc is Maxwell's equations. One can
tell you how much force a magnet excerts on a charged particle in
motion. The other one tries to explain how the universe works.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:20 EST