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.
Key Porting Differences from LinuxThreads to NPTL
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
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!!!
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.
Welcome the world of standards. How many OS’s or threads packages are there that are fully POSIX compliant, anyway?
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
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.
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.
Could you elaborate on that last statement?
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.
> 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).
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)
i did. you’re right.
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.
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.
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.
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.
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…).
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.