DevOps, CI/CD and Automation

I have an application that uses a static library that in turn does a dlopen on a dynamic library. The general flow is that to perform a task, it does a dlopen of this shared library, and when the task is complete it performs a dlclose. My application is multithreaded, and performs this task is multiple threads. So, I have multiple threads that are (in parallel) opening the library, performing the task, closing the library. Every so often (usually after several hours of running), I get a core dump. When I look at the stack, one thread is performing the task and thus is accessing the shared library (this is the thread that generated the segv). What is interesting is another thread is inside the static initialization associated with the dlopen.

I was under the impression that dlopen/dlcose are reference counted, so if I open the same library more than 1 time, it will just increment the reference count but not actually reload the library, and thus not reinitialize the static variables. Is this not the case? I am also under the impression that dlopen and dlclose are thread safe, so that I do not need to add additional protections around the opening and closing of the library. So, am I wrong in thinking that the static initialization should not be happening when loading the library a second time?

I do not know for sure what is causing my segmentation fault at this time, but it seems strange that one thread is doing static initialization associated with a dlopen while another thread is accessing the library (potentially accessing one of the static variables in the library).