Performance cost of threading constructs: missed optimisations and memory allocation

We are experiencing a strange phenomenon in which the inclusion of a header file results in a 5-10% performance penalty in certain memory-allocation-intensive workloads.

This header file declares a thread pool as a global variable. This thread pool is never used in any capacity (yet) in the application. That is, apart from the creation of this static thread pool at program startup, the application is completely single-threaded. The performance penalty disappears once the header is removed.

From a bit of researching, it seems like a multithreaded application can incur in some performance penalty due to certain compiler optimisations not being possible any more. Is it possible that such optimisations are being turned off whenever a threading-related construct is instantiated in any form or capacity?

Or, since the performance penalty seems to be most evident while performing numerous memory allocations, is it possible that during the compilation/linking phase the compiler realises that threading constructs are instantiated and thus it switches to a thread-safe memory allocator?

This happens on a Linux 64 bit workstation, with both GCC and clang. The standard threading primitives from C++11 are being used.