Many systems impose restrictions on the size of the thread-local memory block, in fact often rather tight limits.
The solution is to have errno be a variable that looks as if it is global, but is physically stored in a per-thread memory pool, the thread-local storage.
Instead, each thread might accumulate into a thread-local variable, thereby eliminating any possibility of a race condition, thereby removing the need for locking.
The TlsGetValue and TlsSetValue functions are then used to read and write a memory address to a thread-local variable identified by the TLS slot index.
In the Pthreads API, memory local to a thread is designated with the term Thread-specific data.
In addition pthread_key_create can optionally accept a destructor function that will automatically be called at thread exit, if the thread-specific data is not NULL.
The destructor receives the value associated with the key as parameter so it can perform cleanup actions (close connections, free memory, etc.).
Apart from relying on programmers to call the appropriate API functions, it is also possible to extend the programming language to support thread local storage (TLS).
Example usage: In C11,
[2] C++11 introduces the thread_local[3] keyword which can be used in the following cases Aside from that, various compiler implementations provide specific ways to declare thread-local variables: On Windows versions before Vista and Server 2008, __declspec(thread) works in DLLs only when those DLLs are bound to the executable, and will not work for those loaded with LoadLibrary() (a protection fault or data corruption may occur).
This abstraction naturally maps to thread-specific storage, and Lisp implementations that provide threads do this.
For instance the standard variable *print-base* determines the default radix in which integers are printed.
In Cocoa, GNUstep, and OpenStep, each NSThread object has a thread-local dictionary that can be accessed through the thread's threadDictionary method.