Native POSIX thread library

from Wikipedia, the free encyclopedia

The Native POSIX Thread Library ( NPTL ) is a modern implementation of threading - Library for Linux . It is used in conjunction with the GNU C Library (glibc) and allows Linux programs to use POSIX threads (pthreads).

history

The LinuxThreads threading library had existed for Linux since kernel version 2.0 , the basic design principles of which had come about under the influence of the 1996 restrictions of the Linux kernel and libc5. Linux had no real support for threads in the kernel, but it knew the clone () system call, which created a copy of the calling process with the same address space. LinuxThreads used this system call to simulate thread support in userspace . The library was continuously improved, but conceptually outdated and limited.

The following problems with the existing LinuxThreads implementation have been identified:

  • It requires a manager thread in the process, which creates additional threads, cleans them up and channels the signal handling.
  • It is not POSIX- compliant because it is not possible, for example, to send a signal to the entire process, or the kernel has to ensure that signals such as SIGSTOP and SIGCONT are passed through to all threads in the process.
  • The performance is poor under load because the signal system is used for synchronization . This also affects the stability .
  • Each thread incorrectly has its own process ID .
  • Only a maximum of 8192 threads were possible on the important IA-32 architecture.

To solve the existing problems, additional infrastructure in the kernel and a rewritten threading library were required. Two competing projects were started: Next Generation POSIX Threads (NGPT) under the direction of IBM and NPTL under the leadership of the Red Hat kernel and glibc programmers Ingo Molnár and Ulrich Drepper . Because it became clear that the NPTL would prevail in practice, the NGPT project was discontinued in mid-2003.

The NPTL team set the following goals for their new library:

  • POSIX conformity to make userspace source text more portable
  • effective use of SMP and good scalability to improve performance on multiprocessor systems
    • Building on this: NUMA support
  • little generation effort per thread
  • Compatibility with LinuxThreads , that is, old programs should run with the NPTL without recompiling.

Under these conditions, work on the new Native POSIX Thread Library began in mid-2002. In August / September 2002 the Linux kernel 2.5 was prepared for the NPTL. For this it was necessary to introduce some new system calls and to optimize existing ones. In the first benchmarks, 100,000 parallel threads could be generated on an IA-32 system within 2 seconds; without NPTL, thread generation alone took almost 15 minutes. Despite this load, the test system remained usable at almost the same speed.

Red Hat Linux 9 was the first Linux distribution in which the NPTL was used in a patched 2.4 kernel (and its users sometimes became involuntary beta testers as a result). Practically all modern distributions now use NPTL if they are using a kernel version 2.6 or higher.

concept

NPTL works in a similar way to LinuxThreads . The kernel is still managing processes, not threads, and new threads are created with one called by the NPTL clone(). However, the NPTL requires special kernel support and implements synchronization mechanisms in which threads are put to sleep and woken up again. These are futexes used.

The NPTL is a so-called 1: 1 threading library. The pthread_create()threads created by the user with the function are in a 1-to-1 relationship with processes in the scheduler queues of the kernel. This is the simplest threading implementation imaginable. The alternative would be m: n. Typically there are more threads in userspace than there are processes in the kernel. The threading library would then be responsible for distributing the processor time among the individual threads in the process. With this concept very fast context changes would be possible, since the number of necessary system calls is minimized, but on the other hand the complexity would be increased and priority inversion could occur more easily .

literature