Differencebetween Nptl and Posix Threads

What is the difference between NPTL and POSIX threads?

POSIX threads (pthread) is not an implementation, it is a API specification (a standard, on paper, in english) of several functions whose name starts with pthread_ and which are defined in <pthread.h> header. POSIX is also a set of specifications.

NPTL is now inside GNU Libc on Linux and is (or at least tries very hard to be) an implementation of POSIX threads. It is a bunch of source and binary code on your Linux system.
An application compiled with gcc -pthread and linked with -pthread uses NPTL code on Linux today.

addenda

There exist alternative implementations of pthread-s: on Linux, the MUSL Libc aims to be Posix compliant (which means having pthreads); on other Posix systems (AIX, Solaris, ...) you also have pthreads (but they are not NPTL or Glibc).

Why two threads in NPTL have different pid in Ubuntu12.04

The two threads do share one PID, as shown by your first example.

htop is showing you TIDs (Thread IDs) in the field marked as PID.

Linking against NPTL for pthread function pthread_condattr_setclock

From what I been able to find out, the pthread header and library in /usr/include and /usr/lib respectively are the old LinuxThreads implementations and my supposition is that they are there for backwards compatability (i.e. you should build against the old interface) but at run time the NPTL implementation is used (which has an interface that is a superset of the LinuxThreads interface).

Therefore, you can only use the new NPTL interface (i.e. if you require some extra functionality) if you know that you need it and, crucially, you know that the NPTL interface will be available at runtime.

Are there specific defines of linuxthreads and nptl

Doesn't look like this is possible, you can change the implementation at load time so there's no way to know at compile time no matter what you do.

from the pthreads man page:

On systems with a glibc that supports
both LinuxThreads and NPTL (i.e.,
glibc 2.3.x), the LD_ASSUME_KERNEL
environment variable can be used to
override the dynamic linker's default
choice of threading implementation.
This variable tells the dynamic linker
to assume that it is running on top of
a particular kernel version. By
specifying a kernel version that does
not provide the support required by
NPTL, we can force the use of
LinuxThreads. (The most likely reason
for doing this is to run a (broken)
application that depends on some
nonconformant behavior in
LinuxThreads.) For example:

bash$ $( LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls | grep libc.so | \
                awk '{print $3}' ) | egrep -i 'threads|ntpl'
linuxthreads-0.10 by Xavier Leroy

Not to mention that the two implementations are (mostly) binary compatible, so basically you CANNOT know at compile time which thread library will be used, EVER, because it might change depending on the environment variables present when your program is run, or someone could copy the binary from an NPTL system to a LinuxThreads system. You just can't do it, because it's not something that is known at compile time, at least not in a way you can rely on.

You'll have to find some way to use run time detection, or maybe you could update your post with information about WHY you want to do this and someone could maybe offer advice about how to accomplish it some other way, or how to make it possible to use run time detection of which pthreads is in use.

The other possible solution is to add an option to your configure script and make the person compiling it choose.

Distinction between processes and threads in Linux

These confusions all stem from the fact that the kernel developers originally held an irrational and wrong view that threads could be implemented almost entirely in userspace using kernel processes as the primitive, as long as the kernel offered a way to make them share memory and file descriptors. This lead to the notoriously bad LinuxThreads implementation of POSIX threads, which was rather a misnomer because it did not give anything remotely resembling POSIX thread semantics. Eventually LinuxThreads was replaced (by NPTL), but a lot of the confusing terminology and misunderstandings persist.

The first and most important thing to realize is that "PID" means different things in kernel space and user space. What the kernel calls PIDs are actually kernel-level thread ids (often called TIDs), not to be confused with pthread_t which is a separate identifier. Each thread on the system, whether in the same process or a different one, has a unique TID (or "PID" in the kernel's terminology).

What's considered a PID in the POSIX sense of "process", on the other hand, is called a "thread group ID" or "TGID" in the kernel. Each process consists of one or more threads (kernel processes) each with their own TID (kernel PID), but all sharing the same TGID, which is equal to the TID (kernel PID) of the initial thread in which main runs.

When top shows you threads, it's showing TIDs (kernel PIDs), not PIDs (kernel TGIDs), and this is why each thread has a separate one.

With the advent of NPTL, most system calls that take a PID argument or act on the calling process were changed to treat the PID as a TGID and act on the whole "thread group" (POSIX process).

Difference between -pthread and -pthreads for C/C++ on Ubuntu 14.04

According to the GCC man page, -pthread and -pthreads are architecture-specific flags. These flags are not both available for all archs. Where both flags are available, they appear to be synonyms for each other. So without seeing your exact error output, my best guess is that the error you're running into is that the "-pthreads" flag to GCC is not available for your arch.

I suggest you read the man page for your compiler to get more information about what options are available for your particular build of your compiler.

What's the difference between GNU_LIBC_VERSION and GNU_NPTL_VERSION?

The NPTL project which first implemented pThreads on Linux was a separate project initially adding kernel support and providing its own library.

When it was stable enough it was merged into glibc. I would assume that those two versions are identical on all reasonably up-to-date installations.

On Ubuntu 8.10 the output is like this:

$ getconf GNU_LIBC_VERSION
glibc 2.8.90
$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.8.90

---

Related Topics