In the GCC C/C++ runtime for Linux, is there a mutex that is locked during both shared library dynamic loading (with dlopen()) and the initialization of a thread_local variable? If the thread_local variable is declared within a function, it seems like this mutex is locked whenever the initialization point of the variable is traversed during execution. (Presumably to check whether the variable has already been initialized.) In dlopen(), this mutex seems to be locked during dynamic initialization of non-locals in the shared library.
This is an example of a call (from a gdb backtrace) which (I think) is locking the mutex, in order to do initialization of a thread_local variable (or check if it was already initialized).
#4 0x00007ffbf6560daa in __cxa_thread_atexit_impl (func=<optimized out>, obj=0x7ffbf52646a0, dso_symbol=0xd48008) at cxa_thread_atexit_impl.c:117
117 __rtld_lock_lock_recursive (GL(dl_load_lock));