Thread safety of new and delete

[Simeon Zlatarev]

First, I would like to apologize if the question has been asked before. I
tried to find answers from the web, but had no luck. (Nothing definite.)

The gcc manual states, if I understand correctly with my interpretation,
that concurrent mutation of STL objects is not thread-safe. But if the
program never modifies the same STL objects concurrently, the compiler makes
sure that barriers or other measures are placed in the STL code, so that the
program works as intended. (Of course, memory and compiler barriers in the
program's synchronization logic are still responsibility of the program's
author.) In summary, STL is not inherently thread-safe, but is
threads-aware.

New and delete, probably relying on malloc and free, do mutate shared state.
Does this mean that concurrent allocation and freeing of memory using those
methods is unsafe? If those operations are thread-safe on multithreading
configurations, what configuration options are necessary to enable this
safety. Does building the gcc compiler and the libraries with one of the
multi-threading models (like --enable-threads=posix) and then compiling the
executable with the respective multi-threading support (like -pthread)
sufficient?

I would like to ask also, if there is a way to determine the multi-threading
model used to compile a shared library object (like libgcc.so or
libstdc++.so) on say, a client machine, either at run-time or during
installation/debugging? For example, if a client has some strange behavior
and I need to diagnose possible issues with compatibility of the shared
objects, is there a way to interrogate the system somehow?
(The best answer I know for the above so far, is to check the version
information of the compiler, assuming that there is one compiler on the
system that was built with the used shared objects.)

Thanks and Regards