Linked by Eugenia Loli on Fri 4th Aug 2006 23:31 UTC, submitted by IdaAshley
Linux The LinuxThreads project originally brought multithreading to Linux, but didn't conform to POSIX threading standards. The introduction of Native POSIX Thread Library (NPTL) however, overcame many of these disadvantages. This article describes some of the differences between these two Linux threading models for developers who may need to port their applications or who simply want to understand where the differences lie.
Order by: Score:
man
by deanlinkous on Sat 5th Aug 2006 02:26 UTC
deanlinkous
Member since:
2006-06-19

I wish I were a dev. I would really get off on this article if I were but sadly it flies right over my head. I love DeveloperWorks website though, fantastic source of info!!!

Reply Score: 2

RE: man
by bservies on Sat 5th Aug 2006 03:30 UTC in reply to "man"
bservies Member since:
2006-05-27

Nah. Soon you would be as bitter as the rest of us that 2 packages with the same API work in subtly different ways. Ways that always seem to require "workarounds" that suck.

Reply Score: 5

RE[2]: man
by Vanders on Sat 5th Aug 2006 11:04 UTC in reply to "RE: man"
Vanders Member since:
2005-07-06

Welcome the world of standards. How many OS's or threads packages are there that are fully POSIX compliant, anyway?

Reply Score: 2

RE[3]: man
by Ithamar on Sat 5th Aug 2006 14:20 UTC
Ithamar
Member since:
2006-03-20

Well, if you could find one, it would probably be pretty useless in a lot of cases. Most of the 'non-compliant' extensions to the POSIX standard was because of lacking functionality....

It is all the standard's fault ;)

Reply Score: 1

RE[4]: man
by Cloudy on Sat 5th Aug 2006 16:19 UTC in reply to "RE[3]: man"
Cloudy Member since:
2006-02-15

Hey! We did the best we could ;)

You try getting the hard realtime community, the threads as a programming model community, and the threads for SMP community to agree on a set of semantics some time.

Once NPTL is fully deployed, Linux will have half a threading system. Linus says it'll never have the other half, but I've got a bet that it will by 2015, if it's still around then.

Reply Score: 1

RE[5]: man
by bservies on Sat 5th Aug 2006 16:24 UTC in reply to "RE[4]: man"
bservies Member since:
2006-05-27

Actually, I have been pretty happy with NPTL. I don't think it is quite as solid as, say, Solaris threading, but it hasn't had as much time to cook, either.

Reply Score: 2

RE[5]: man
by rayiner on Sat 5th Aug 2006 17:48 UTC in reply to "RE[4]: man"
rayiner Member since:
2005-07-06

Could you elaborate on that last statement?

Reply Score: 2

RE[6]: man
by Cloudy on Sat 5th Aug 2006 19:33 UTC in reply to "RE[5]: man"
Cloudy Member since:
2006-02-15

For maximum efficiency across all SMP threaded workloads, you need the option of an M:N thread package with both kernel level and library level scheduling.

Linus and I have debated this off and on since 2000 and he says that Linux will never have M:N threads. But then, in 2000 he thought it would never have Posix threads. ;)

Reply Score: 1

RE[5]: man
by corentin on Sun 6th Aug 2006 07:38 UTC in reply to "RE[4]: man"
corentin Member since:
2005-08-08

> You try getting the hard realtime community, *the threads as a programming model community*, and the threads for SMP community to agree on a set of semantics some time.

The "threads as a programming model" community :] (a.k.a. the crack smokers).

Reply Score: 1

RE[6]: man
by anevilyak on Sat 5th Aug 2006 19:32 UTC
anevilyak
Member since:
2005-09-14

I'd presume he means an M:N threading model but I might be wrong.

Browser: Mozilla/5.0 (Danger hiptop 2.0; U; AvantGo 3.2)

Reply Score: 1

RE[7]: man
by Cloudy on Sat 5th Aug 2006 19:34 UTC in reply to "RE[6]: man"
Cloudy Member since:
2006-02-15

i did. you're right. ;)

Reply Score: 1

M:N is just too complicated
by abraxas on Sat 5th Aug 2006 23:46 UTC
abraxas
Member since:
2005-07-07

The problem with an M:N approach is that it is just too complicated. I prefer the KISS approach and it seems to work well when it comes to threading, at least for Linux. Userspace/Kernelspace synchronization becomes such a hassle with M:N that it is not even worth it.

I prefer NPTL over something like NGPT which had an M:N threading model. In fact NPTL beat the pants off of NGPT and that's why NPTL was chosen over NGPT. We have Ingo Molnar to thank for that as he was the one that improved Linux scheduling to the point that NPTL became more viable than an M:N approach like NGPT.

I have used NPTL for quite some time now but I experimented with NGPT at one time because it was available for Redhat. In my not so scientific experience NGPT could not keep up with NPTL and real benchmarks show the same.

Reply Score: 1

m:n
by Cloudy on Sun 6th Aug 2006 01:55 UTC
Cloudy
Member since:
2006-02-15

If userspace/kernelspace synchronization becomes a hassle with your m:n thread model, you need to fix the model, because it doesn't have to be.

A properly done m:n thread model is transparent to user space applications, has precisely the same performance as a 1:1 model for applications where m:n doesn't matter, and has better performance in those cases where it does.

The Cray m:n model in Unicos on the X/MP and Y/MP series is an existance proof of such an implementation.

Reply Score: 1

RE: m:n
by abraxas on Sun 6th Aug 2006 22:41 UTC in reply to "m:n"
abraxas Member since:
2005-07-07

A properly done m:n thread model is transparent to user space applications, has precisely the same performance as a 1:1 model for applications where m:n doesn't matter, and has better performance in those cases where it does.

If you can find or code an M:N threading model for Linux that outperforms NPTL I would love to see it. The inherent complexity just begs for bugs, and IMHO isn't worth the effort unless significant performance increases can be attained.

Reply Score: 1

RE[2]: m:n
by Cloudy on Mon 7th Aug 2006 06:10 UTC in reply to "RE: m:n"
Cloudy Member since:
2006-02-15

If you can find or code an M:N threading model for Linux that outperforms NPTL I would love to see it. The inherent complexity just begs for bugs, and IMHO isn't worth the effort unless significant performance increases can be attained.

Tempting, but no, thanks. I'm not up to the up-hill battle it'd take to get Linus to change his mind.

Maybe next year at this time, after I finish my current embedded OS project.

Reply Score: 1

Yoke
Member since:
2005-08-28

Solaris had MxX threading but replaced it with a 1:1 implementation (http://www.sun.com/software/whitepapers/solaris9/multithread.pdf), and FreeBSD seems to be going in the same direction (http://thread.gmane.org/gmane.os.freebsd.devel.threading/3515/focus...).

Reply Score: 2

Cloudy Member since:
2006-02-15

The Sun whitepaper starts with a note "this paper does not discuss the relative merits of MxN and 1:1 threading models."

It is possible that the constraints of the Solaris design prohibit implementing a good thread model, or that the constraints of Sun's business do.

As far as I know, the FreeBSD discussion ended inconclusively, again, and really hinged on the issue of make FBSD more Linux-like and not on the choice of MxN versus 1:1.

Reply Score: 1