3 ms·

Wait, are you saying that compilers can cache the pointer to TLS across function calls, even when inlining is disabled? Does this mean that the OP article is wr

Wait, are you saying that compilers can cache the pointer to TLS across function calls, even when inlining is disabled? Does this mean that the OP article is wrong when it says to use a separate getter/setter function for each TLS variable (even if we manually disable inlining for those accessor functions)? Also, regarding shared libraries, how can compiler cache the TLS address, since the compiler versions that compiled the shared library may be different that the version which is compiling the executable that links to it, and thus may have different caching behaviours?

gpderetta 6y ago
thread_local x; void foo() { x = 10; // x in thread 1 foo(); // moves this coroutine to thread 2 x = 20; // might erroneously write to x of thread 1 The issue with dynamic libraries is that TLS computation is slightly more expensive (as the TLS offset is not statically known) so the compiler is more likely to cache the TLS address computation. So the above function might be more likely to "miscompiled" if is part of a .so translation unit. edit: also yes, forcing inlining off is not guaranteed to disable cross procedure optimizations. At the very least you have to disable function cloning. In fact I see that GCC now has attribute noipa which is probably a better solution.
- HexDecOctBin 6y ago
  Yes, but what you describe only happens if you try to access the TLS variables directly. If I put all the TLS variable in a .so file, and only access them through getter/setter functions (also part of the .so), can compiler optimisations still screw things up? It seems to me that unless there is some runtime optimisation going on, this method should be safe.
  - gpderetta 6y ago
    Putting the code to a separate .so is very unlikely to break, unless C++ compilers start doing code generation at dynamic link time. LTO is a thing though, putting it in a separate translation unit doesn't help when static linking.

gpderetta 6y ago

thread_local x; void foo() { x = 10; // x in thread 1 foo(); // moves this coroutine to thread 2 x = 20; // might erroneously write to x of thread 1 The issue with dynamic libraries is that TLS computation is slightly more expensive (as the TLS offset is not statically known) so the compiler is more likely to cache the TLS address computation. So the above function might be more likely to "miscompiled" if is part of a .so translation unit. edit: also yes, forcing inlining off is not guaranteed to disable cross procedure optimizations. At the very least you have to disable function cloning. In fact I see that GCC now has attribute noipa which is probably a better solution.

HexDecOctBin 6y ago
Yes, but what you describe only happens if you try to access the TLS variables directly. If I put all the TLS variable in a .so file, and only access them through getter/setter functions (also part of the .so), can compiler optimisations still screw things up? It seems to me that unless there is some runtime optimisation going on, this method should be safe.
- gpderetta 6y ago
  Putting the code to a separate .so is very unlikely to break, unless C++ compilers start doing code generation at dynamic link time. LTO is a thing though, putting it in a separate translation unit doesn't help when static linking.