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.
Post a Comment
Member since:
2006-06-19
Member since:2006-05-27
Member since:2005-07-06
Member since:
2006-03-20
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.
Member since:2006-05-27
Member since:2005-07-06
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.
Member since:2005-08-08
Member since:
2005-09-14
Member since:2006-02-15
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.
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.
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.
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.
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...).
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.