Content deleted Content added
Line 10:
NPTL uses a similar approach to LinuxThreads, in that the primary abstraction known by the kernel is still a process, and new threads are created with the clone() [[system call]] (called from the NPTL library). However, NPTL requires specialised kernel support to implement (for example) the contended case of synchronisation primitives which might require threads to sleep and be re-awoken. The primitive used for this is known as a [[futex]].
NPTL is a so-called 1×1 threads library, in that threads created by the user (via the pthread_create() library function) are in 1-1 correspondence with schedulable entities in the kernel (processes, in the Linux case). This is the simplest possible threading implementation
An alternative to NPTL's 1×1 model is the m×n model where there are typically more userland threads than schedulable entities. In this implementation, the threading library is responsible for scheduling user threads on the available schedulable entities; this makes [[context_switch|context switching of threads]] very fast, as it avoids system calls. However, this increases complexity, and is liable to suboptimal scheduling without extensive (and expensive) coordination between the userland scheduler and the kernel scheduler, and the likelihood of [[priority inversion]].
NPTL was first released in Red Hat 9.0. Old-style POSIX threading is known for having trouble with threads that refuse to yield to the system occasionally because it does not take the opportunity to preemptively yield them when it arises, something that Windows was known to do better at the time. Red Hat claimed that NPTL fixed this problem in an article on the [[Java programming language|Java]] website about Java on Red Hat 9.
NPTL has been part of [[Red Hat Enterprise Linux]] since version 3, and is now a fully integrated part of [[glibc]].
==See also==
| |||