http://www.osnews.com/story/15394/Key_Porting_Differences_from_LinuxThreads_to_NPTL Exploring the Future of Computing en-us Copyright 2001-2013, David Adams adam+nospam@osnews.com Wed, 22 May 2013 00:08:19 GMT http://www.osnews.com/images/osnews.gif http://www.osnews.com http://www.osnews.com/thread?149349 http://www.osnews.com/thread?149349 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!!! Sat, 05 Aug 2006 02:26:00 GMT donotreply@osnews.com (deanlinkous) Comments http://www.osnews.com/thread?149355 http://www.osnews.com/thread?149355 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. Sat, 05 Aug 2006 03:30:00 GMT donotreply@osnews.com (bservies) Comments http://www.osnews.com/thread?149388 http://www.osnews.com/thread?149388 Welcome the world of standards. How many OS's or threads packages are there that are fully POSIX compliant, anyway? Sat, 05 Aug 2006 11:04:00 GMT donotreply@osnews.com (Vanders) Comments http://www.osnews.com/thread?149400 http://www.osnews.com/thread?149400 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 Sat, 05 Aug 2006 14:20:00 GMT donotreply@osnews.com (Ithamar) Comments http://www.osnews.com/thread?149407 http://www.osnews.com/thread?149407 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. Sat, 05 Aug 2006 16:19:00 GMT donotreply@osnews.com (Cloudy) Comments http://www.osnews.com/thread?149408 http://www.osnews.com/thread?149408 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. Sat, 05 Aug 2006 16:24:00 GMT donotreply@osnews.com (bservies) Comments http://www.osnews.com/thread?149416 http://www.osnews.com/thread?149416 Could you elaborate on that last statement? Sat, 05 Aug 2006 17:48:00 GMT donotreply@osnews.com (rayiner) Comments http://www.osnews.com/thread?149421 http://www.osnews.com/thread?149421 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) Sat, 05 Aug 2006 19:32:00 GMT donotreply@osnews.com (anevilyak) Comments http://www.osnews.com/thread?149422 http://www.osnews.com/thread?149422 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. Sat, 05 Aug 2006 19:33:00 GMT donotreply@osnews.com (Cloudy) Comments http://www.osnews.com/thread?149423 http://www.osnews.com/thread?149423 i did. you're right. Sat, 05 Aug 2006 19:34:00 GMT donotreply@osnews.com (Cloudy) Comments http://www.osnews.com/thread?149450 http://www.osnews.com/thread?149450 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. Sat, 05 Aug 2006 23:46:00 GMT donotreply@osnews.com (abraxas) Comments http://www.osnews.com/thread?149459 http://www.osnews.com/thread?149459 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. Sun, 06 Aug 2006 01:55:00 GMT donotreply@osnews.com (Cloudy) Comments http://www.osnews.com/thread?149487 http://www.osnews.com/thread?149487 > 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). Sun, 06 Aug 2006 07:38:00 GMT donotreply@osnews.com (corentin) Comments http://www.osnews.com/thread?149509 http://www.osnews.com/thread?149509 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...). Sun, 06 Aug 2006 10:42:00 GMT donotreply@osnews.com (Yoke) Comments http://www.osnews.com/thread?149666 http://www.osnews.com/thread?149666 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. Sun, 06 Aug 2006 22:41:00 GMT donotreply@osnews.com (abraxas) Comments http://www.osnews.com/thread?149729 http://www.osnews.com/thread?149729 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. Mon, 07 Aug 2006 06:03:00 GMT donotreply@osnews.com (Cloudy) Comments http://www.osnews.com/thread?149730 http://www.osnews.com/thread?149730 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. Mon, 07 Aug 2006 06:10:00 GMT donotreply@osnews.com (Cloudy) Comments