Talk:Native POSIX Thread Library

This is the talk page for discussing improvements to the Native POSIX Thread Library article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Computing Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Low	This article has been rated as Low-importance on the project's importance scale.

Software: Computing Low‑importance

	This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.SoftwareWikipedia:WikiProject SoftwareTemplate:WikiProject Softwaresoftware
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Computing.

Linux Low‑importance

	Linux portal This article is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of Linux on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.LinuxWikipedia:WikiProject LinuxTemplate:WikiProject LinuxLinux
Low	This article has been rated as Low-importance on the project's importance scale.

I'm not sure

I'm not sure that the threading experiment quoted on here is necessarily all that indicative of how good threading is in NPTL - after all, it's a Java environment, so you're more likely to be comparing how well threading is supported in the JVMs on the two platforms, than the thread library itself.

Perhaps it should be removed and replaced with a benchmark comparison of NPTL and LinuxThreads, with perhaps a comparison to threads on Solaris too? Sigbusyff

I think this comparison is meaningless. The result doesn't entirely depends on the threading implementation. It has something to do with the implementation of JVM. However I am not tring to say that SUN produced a worse JVM for Linux. Zhangle

Who is Edward Rice?

Who is Edward Rice? Where is this research? If it isn't available to be read anywhere, why is it referenced in this http://en.wiki.x.io/wiki/NPTL entry. Also, if the research isn't available or is known to be faulty why is it still referenced? Considering these comments I believe it to be a better idea to remove the paragraph and wait for a decent study comparing LinuxThreads to NPTL which is more useful than a comparison to another Operating System. Thanks, Christopher Warner--64.61.118.58 15:31, 30 August 2005 (UTC)[reply]

I've removed the paragraph on NPTL and Windows threading in its entirety. Christopher Warner 216.254.126.222 03:11, 13 September 2005 (UTC)[reply]

Added a handy test

Added a handy test for determining version from the command line (common knowledge). Also, I did some research on threading performance for Dr. Dobbs Magazine in May or June, and could add that in when I regain complete copyright. Big advantage is in thread creation; small advantage in handling thread contention. --Bluejack

I tested the 'getconf GNU_LIBPTHREAD_VERSION' utility on a Redhat system and it returned: NPTL 2.3.4. Interestingly enough, rpm -qa | grep nptl indicates that the system has the nonptl versions of many libraries installed. The nptl libraries in /usr/lib/nptl do not exist on this system so it appears that the system defaults to using Linux threads. I question the validity of the getconf GNU_LIBPTHREAD_VERSION test to determine whether NPTL is really supported on a system. --RandomTask

The system is either using NPTL or it is not. This depends on the way GlibC is compiled, it's one or the other, as there is no fallback system. So you should not need to question if it is really supported or not. Christopher Warner

glibc is compiled twice, once for NPTL and once for LinuxThreads. The NPTL libs are installed to lib/tls and used by default. EdC 07:49, 14 March 2006 (UTC)[reply]

The text says that 1x1 threading "is the simplest possible threading implementation". However, most OS textbooks say that Nx1 threads (like GNU-Pth) can be considered simpler, because they are very easy to implement and need no kernel intervention. Thanks - Carlos Maziero, 200.192.112.146 11:13, 4 April 2007 (UTC)[reply]

The article implies NPTL requires kernel mods, but only mentions standard inclusion in glibc. Could someone clarify this and update current level of adoption (i.e., is this standard in the 2.6 kernel? Is this in, e.g., Ubuntu now as well?)? SimonFunk 20:48, 20 July 2007 (UTC)[reply]

The article also implies the LinuxThreads implementations require user-space context switches and that the kernel scheduler is not involed. I fairly confident that this is not the case. When clone is called on a process the child process is still managed by the kernel scheduler. Beavix 02:30, 10 August 2007 (UTC)[reply]

test with 100.000 threads

The test mentioned in the text is from 2002. I think it should be removed and replaced by more up-to-date info if that is to be had. --MarSch 09:35, 24 August 2006 (UTC)[reply]

The test results mentioned here are also seen in an article on LinuxJournal Introducing the 2.6 Kernel published on Thu, 2003-05-01. However, it is unclear if that is the source of the test results, or if that article is merely referring to test results reported elsewhere.
--ViM 11:42, 25 September 2006 (UTC)[reply]

Any news on this ? I tried creating 20,000 threads on a 2.6.25 kernel with a 2.7 libc. The source is here http://patraulea.com/hacks/nptl-test/ . My numbers on an 8-cpu 64bit Xeon machine are:

threads	runtime (sec)
5000	1.0
10000	3.9
20000	24.5

Hardly anything like the numbers in nptl-design.pdf . —Preceding unsigned comment added by 195.37.79.197 (talk) 20:39, 18 May 2008 (UTC)[reply]

Translation into Chinese Wikipedia

The 13:30, 12 November 2008 Lightbot version of this article is translated into Chinese Wikipedia.--Wing (talk) 12:13, 13 December 2008 (UTC)[reply]

Reference Out Of Date

The pdf document linked in the article (http://people.redhat.com/drepper/nptl-design.pdf) has the following disclaimer:

This document is completely, utterly out of date when it comes to descriptions of the limitations of the current implementation. Everybody referring to this document to document shortcomings of NPTL is either a moron who hasn’t done her/his homework and researched the issue, or is deliberately misleading people as it happens too often with publications done by the Evil from the North-West.

QBasicer (talk) 00:54, 14 September 2009 (UTC)[reply]

question

fork and vfork have always allowed "extra processes and possibly running on other cpu" in unix and linux (since i386 lets say) - and also parallel computing code was available before linux first release (though it was coded in applications not the kernel). before kernel 2.6 there were pleanty of "ways" to cross talk betwen processes which could be light weight if desired.

i can't think of a reason tls would be "required" it contains ALLOT of assembler hacks special memory tagging special depends setup and this and that

"is a thread not a process" doesn't sound like a reasonable argument

incorrectnes in article - microsoft trolling in article

"something that Windows was known to do better at the time"

ABSOLUTELY NOT. at the time Windows crashed continuall if used for anything other than solitair. the libraries attacked the developers that bought them.

Windows DID NOT HAVE pre-emtive multi-taksing before unix or linux. Furthermore I have a published letter from intel informing Microsoft NOT to put intel chip in the mode they put it in (known to cause lock ups) - which microsoft refused to comply with. (sybex - programming the intel i386)

Windows was WELL KNOWN for freezing while reading a floppy (and during other system events - often crashing the computer).