{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

NPTL2 - The Native POSIX Thread Library for Linux Ulrich...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
Draft The Native POSIX Thread Library for Linux Ulrich Drepper Red Hat, Inc. [email protected] Ingo Molnar Red Hat, Inc. [email protected] January 30, 2003 Today’s demands for threads can hardly be satisfied by the Linux- Threads library implementing POSIX threads which is currently part of the standard runtime environment of a Linux system. It was not written with the kernel extensions we have now and in the near future available, it does not scale, and it does not take modern processor architectures into account. A completely new design is necessary and this paper will outline the design we came up with. 1 The First Implementation The LinuxThreads implementation which today is Linux’s standard POSIX thread li- brary is based on the principles outlined by the kernel developers at the time the code was written (1996). The basic assumption is that context switches among related pro- ceses are fast enough to handle each user-level thread by one kernel thread . Kernel processes can have various degrees of relationship. The POSIX thread specification requires sharing of almost all resources. Missing thread-aware ABIs for the target architectures, the design did not use thread registers. The thread-local memory was instead located using fixed relation- ships between the stack pointer and the position of the thread descriptor. In addition, a manager thread had to be created to be able to implement the correct semantics with respect to signals, thread creation, and various other parts of process management. Perhaps the biggest problem was the absence of usable synchronization primitives in the kernel which forced the implementation to resort to using signals. This, together with the concept of kernel thread groups missing in the kernel versions of the time, lead to non-compliant and fragile signal handling in the thread library. 2 Improvements Over Time The code of the thread library was significantly improved over the following six years. The improvements come in two areas: the ABI and the kernel.
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Draft Newly defined ABI extensions allow the use of thread registers or constructs which can work like registers. This was an essential improvement since now locating the thread-local data is no longer a time consuming operation. Locating thread-local data is essential to almost any operation in the thread library itself. The rest of the runtime environment and the user applications need this as well. For some architectures the changes were easy. Some had registers set aside for this purpose, others had special processor features which allow storing values in the execution context. But there were some architectures which were left out since they had neither. Those architectures still rely on the method of calculating the thread-local data position based on the stack address. Beside being quite a slow calculation this also means that the APIs which allow the programmer to select the position and size of the stack cannot be implemented for these architectures. These interfaces are especially important when large numbers of threads are used, either at one time or in succession.
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}