Thread-Local Storage Access Models
Each TLS reference follows one of the following access models. These models are listed from the most general, but least optimized, to the fastest, but most restrictive.
- General Dynamic (GD) - dynamic TLS
-
This model allows reference of all TLS variables, from a dynamic object. This model also supports the deferred allocation of a TLS block when the block is first referenced from a specific thread.
- Local Dynamic (LD) - dynamic TLS of local symbols
-
This model is a optimization of the GD model. The compiler might determine that a variable is bound locally, or protected, within the object being built. In this case, the compiler instructs the link-editor to statically bind the dynamic
tlsoffset
and use this model. This model provides a performance benefit over the GD model. Only one call totls_get_addr
() is required per function, to determine the address ofdtv
0,m. The dynamic TLS offset, bound at link-edit time, is added to thedtv
0,m address for each reference. - Initial Executable (IE) - static TLS with assigned offsets
-
This model can only reference TLS variables which are available as part of the initial static TLS template. This template is composed of all TLS blocks that are available at process startup, plus a small backup reservation. See Program Startup. In this model, the thread pointer-relative offset for a given variable x is stored in the
GOT
entry for x.This model can reference a limited number of TLS variables from shared libraries loaded after initial process startup, such as by means of lazy loading, filters, or
dlopen
(3C). This access is satisfied from a fixed backup reservation. This reservation can only provide storage for uninitialized TLS data items. For maximum flexibility, shared objects should reference thread-local variables using a dynamic TLS model.Note:
Filters can be employed to dynamically select the use of static TLS. A shared object can be built to use dynamic TLS, and act as an auxiliary filter upon a counterpart built to use static TLS. If resources allow the static TLS object to be loaded, the object is used. Otherwise, a fallback to the dynamic TLS object insures that the functionality provided by the shared object is always available. For more information on filters see Shared Objects as Filters. - Local Executable (LE) - static TLS
-
This model can only reference TLS variables which are part of the TLS block of the dynamic executable. The link-editor calculates the thread pointer-relative offsets statically, without the need for dynamic relocations, or the extra reference to the
GOT
. This model can not be used to reference variables outside of the dynamic executable.
The link-editor can transition code from the more general access models to the more optimized models, if the transition is determined appropriate. This transition is possible through the use of unique TLS relocations. These relocations, not only request updates be performed, but identify which TLS access model is being used.
Knowledge of the TLS access model, together with the type of object being created, allows the link-editor to perform translations. An example is if a relocatable object using the GD access model is being linked into a dynamic executable. In this case, the link-editor can transition the references using the IE or LE access models, as appropriate. The relocations that are required for the model are then performed.
The following diagram illustrates the different access models, together with the transition of one model to another model.
Thread-Local Storage Access Models and Transitions
![Thread-Local Storage Access Models and Transitions Thread-Local Storage Access Models and Transitions](img/tlscodemodels.jpg)