Linked by Thom Holwerda on Wed 17th Aug 2005 17:31 UTC
Sun Solaris, OpenSolaris If Sun gets very serious about Solaris 10 on x86 and the Open Solaris project that it hopes will nourish it, Linux vendors had better get very worried. That's because, in the many areas where Linux is miles ahead of Solaris, Sun stands a good chance of catching up quickly if it has the will, whereas in the many areas where Solaris is miles ahead, the Linux community will be hard pressed to narrow the gap.
Thread beginning with comment 20128
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: sunos ahead
by rhavyn on Fri 19th Aug 2005 18:05 UTC in reply to "RE[6]: sunos ahead"
rhavyn
Member since:
2005-07-06

Obviously you don't. Linux never really had threads they had processed which were done using clone(). Since Torvalds contention was that linux's context switch was as quick and lightweight as threads in other OSes linux didn't need threads. However the user level pthread library was bound to one process and scheduled by the library. Now with 1:1 threading each user thread becomes a linux process consuming different PIDs.

I think you should go relearn your Linux history. Torvalds did think that the Linux context switch was fast enough to not require a dedicated threading system. This is why LinuxThreads (which has been around forever) and NPTL both use the clone system call. clone() creates "threads" and "processes" (as defined by other OSes) because it lets you specify whether you want a shared address space between the new and old process or not. So both LinuxThreads and NPTL are 1:1 threading systems. They both create new "threads" with new PIDs. The difference is that NPTL brought along kernel changes which made NPTL follow the POSIX standards closer, particularly regarding signals and it provided a significant speed increase. There was (is?) a user land pth library which follows the pthreads standard, but it is cross platform, not Linux specific. And to the best of my knowledge, no large application ever really used pth.

So, to repeat myself, Linux has used a 1:1 threading model pretty much since the day the LinuxThreads library was written.

In Solaris 8 an alternate pthreads was introduced to do what the linux guys eventually did.

If by "eventually" what you mean is "in the mid 90s" then yes, you are correct.

You really shouldn't talk if you don't understand how stuff works.

That has to be my absolute favorite comment when someone posts something which is completely inaccurate. Now, if you'd like to go learn how Linux threading worked historically, go read up about LinuxThreads. And as a little helper, here is the first sentence from FAQ entry K1 (at http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html):

"LinuxThreads follows the so-called "one-to-one" model: each thread is actually a separate process in the kernel."

Now, I have no idea whether or not the Solaris kernel guys even thought about Linux when they went to a 1:1 threading model. Either way, Linux's "native" thread system has been 1:1 for a long, long time.

Reply Parent Score: 1

RE[8]: sunos ahead
by Arun on Fri 19th Aug 2005 19:26 in reply to "RE[7]: sunos ahead"
Arun Member since:
2005-07-07

There was (is?) a user land pth library which follows the pthreads standard, but it is cross platform, not Linux specific. And to the best of my knowledge, no large application ever really used pth.

What do you think LinuxThreads was? It was a badly implemented pthread library.

That has to be my absolute favorite comment when someone posts something which is completely inaccurate. Now, if you'd like to go learn how Linux threading worked historically, go read up about LinuxThreads. And as a little helper, here is the first sentence from FAQ entry K1 (at http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html):

People living in glass houses....

Accroding to you FAQ. :

At thread creation time, the newly created thread inherits the signal mask of the thread calling pthread_create(). But afterwards, the new thread can modify its signal mask independently of its creator thread.

In all OSes the pthread library uses the pthread_create naming symantics. the LinuxThread library was a badly implemented POSIX thread (pthread) library, hence pthread_create.

Solaris always had a seperate thread library(thr_create) along with a pthread library. The Solaris thread library always supported a 1:1 (bound threads) or M:N behavior.
In Solaris 1:1 threads don't take up new PIDs in the hacky linux sort of way.

Reply Parent Score: 1

RE[9]: sunos ahead
by rhavyn on Fri 19th Aug 2005 21:25 in reply to "RE[8]: sunos ahead"
rhavyn Member since:
2005-07-06

What do you think LinuxThreads was? It was a badly implemented pthread library.

LinuxThreads is still the old Linux thread system and it was 1:1. Which was the point of my original post.

People living in glass houses....

Accroding to you FAQ. :

At thread creation time, the newly created thread inherits the signal mask of the thread calling pthread_create(). But afterwards, the new thread can modify its signal mask independently of its creator thread.


Which has nothing to do with LinuxThreads being 1:1 or not. And I specifically mentioned NPTL fixing the problem with LinuxThreads not following POSIX correctly.

In all OSes the pthread library uses the pthread_create naming symantics. the LinuxThread library was a badly implemented POSIX thread (pthread) library, hence pthread_create.

LinuxThreads was a well implemented POSIX thread library that didn't follow the signal semantics correctly. And they freely admitted it. Linux threads have still been 1:1 for quite a long time.

Solaris always had a seperate thread library(thr_create) along with a pthread library. The Solaris thread library always supported a 1:1 (bound threads) or M:N behavior.
In Solaris 1:1 threads don't take up new PIDs in the hacky linux sort of way.


You can call it hacky or not, it's a 1:1 threading model. It's been that way for a long time.

Reply Parent Score: 1