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
