Static TLS

[Previous] [Next]

Like dynamic TLS, static TLS associates data with a thread. However, static TLS is much easier to use in your code because you don't have to call any functions to take advantage of it.

Let's say that you want to associate a start time with every thread created by your application. All you do is declare the start-time variable as follows:

 _ _declspec(thread) DWORD gt_dwStartTime = 0; 

The _ _declspec(thread) prefix is a modifier that Microsoft added to the Visual C++ compiler. It tells the compiler that the corresponding variable should be placed in its own section in the executable or DLL file. The variable following _ _declspec(thread) must be declared as either a global variable or a static variable inside (or outside) a function. You can't declare a local variable to be of type _ _declspec(thread). This shouldn't be a problem because local variables are always associated with a specific thread anyway. I use the gt_ prefix for global TLS variables and st_ for static TLS variables.

When the compiler compiles your program, it puts all the TLS variables into their own section, which is named, unsurprisingly enough, .tls. The linker combines all the .tls sections from all the object modules to produce one big .tls section in the resulting executable or DLL file.

For static TLS to work, the operating system must get involved. When your application is loaded into memory, the system looks for the .tls section in your executable file and dynamically allocates a block of memory large enough to hold all the static TLS variables. Every time the code in your application refers to one of these variables, the reference resolves to a memory location contained in the allocated block of memory. As a result, the compiler must generate additional code to reference the static TLS variables, which makes your application both larger in size and slower to execute. On an x86 CPU, three additional machine instructions are generated for every reference to a static TLS variable.

If another thread is created in your process, the system traps it and automatically allocates another block of memory to contain the new thread's static TLS variables. The new thread has access only to its own static TLS variables and cannot access the TLS variables belonging to any other thread.

That's basically how static TLS works. Now let's add DLLs to the story. It's likely that your application will use static TLS variables and that you'll link to a DLL that also wants to use static TLS variables. When the system loads your application, it first determines the size of your application's .tls section and adds the value to the size of any .tls sections in any DLLs to which your application links. When threads are created in your process, the system automatically allocates a block of memory large enough to hold all the TLS variables required by your application and all the implicitly linked DLLs. This is pretty cool.

But let's look at what happens when your application calls LoadLibrary to link to a DLL that also contains static TLS variables. The system must look at all the threads that already exist in the process and enlarge their TLS memory blocks to accommodate the additional memory requirements of the new DLL. Also, if FreeLibrary is called to free a DLL containing static TLS variables, the memory block associated with each thread in the process should be compacted.

Alas, this is too much for the operating system to manage. The system allows libraries containing static TLS variables to be explicitly loaded at run time; however, the TLS data isn't properly initialized, and any attempt to access it might result in an access violation. This is the only disadvantage of using static TLS; this problem doesn't occur when you use dynamic TLS. Libraries that use dynamic TLS can be loaded at run time and freed at run time with no problems at all.