With all due respect, as a person who was present for the early evolution of
pthreads, I have to disagree with your assertion of how pthreads came to be.
Pthreads was designed. The initial proposal that was presented to P1003.4
was based on a fully functioning multithreaded programming model already in
use (at DEC SRC, IIRC.) Unfortunately, threads and Un*x don't mix without
breaking something. P1003.4 decided to break the threads model in order to
preserve Unix semantics. The design was fine; if there was a problem it was
with the evolution and the compromises needed.
None of this matters to the fact that, eventually, if one wants C/Un*x
semantics and pthreads (or any multithreaded model) and one want smp
scalability beyond a trivial number of processors, one will have to both
cope with BAD (broken as designed) semantics, and with kernel/library
interaction to resolve performance problems, especially in synchronization.
Grafting 'thread' semantics onto a programming language that wasn't designed
for them (C) and an operating system that had a large body of semantics that
weren't easily made compatible with them (Un*x) left us needing a compromise
that wasn't perfect. That is, after all, what engineering is about: making
the compromises necessary to solve the problem at hand with the tools
available.
After all, as Eric Serveraid was fond of saying "the principle cause of
problems is solutions."
While you are contemplating how to extend and generalize clone operations,
may I suggest checking the literature for "variable weight process" (an idea
I seem to recall being invented at Sequent 15 years ago,) and Brian
Bershad's papers on scheduler activiations?
And don't worry about history. It will come back to haunt you in 10 years.
Marty
-----Original Message-----
From: torvalds@transmeta.com [mailto:torvalds@transmeta.com]
Sent: Sunday, August 27, 2000 4:27 PM
To: linux-kernel@vger.kernel.org
Subject: Re: SCO: "thread creation is about a thousand times faster than
on native Linux"
In article <200008261658.e7QGwhx04244@jupiter.cs.uml.edu>,
Albert D. Cahalan <acahalan@cs.uml.edu> wrote:
>
>First of all, I dare not code it. Linus seems to want Linux not
>strongly tied to the POSIX thread model. We have non-POSIX thread
>libraries, sorry if you don't like it.
Stop this bandying my name about.
The only thing Linus wants is SANE SEMANTICS.
It so happens, that POSIX seems to be insane. Quite frankly, some of
POSIX is utter crap. Cow-dung. In short, shit.
And the reason pthreads have some problems is because the stupid thing
was never designed. It grew out of 1:m implementations and the Sun
threading code.
I want to have pthreads support for Linux. But I do not want the crap in
pthreads to get into the kernel. Which means that I want people to THINK
before they code something up. A 1:1 pthreads implementation simply
isn't going to make it, but something that happens to have the
braindamaged pthreads stuff as a subcase (with some help from user
space) is more than welcome.
This is not something new. I, unlike the POSIX committee, have more taste
than willingness to get reamed up the ass by years of history.
Deal with it.
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