Re: Thread safety of new and delete

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On 7 January 2013 17:05, Simeon Zlatarev wrote:
> 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.

Right.

> 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?

The standard requires that new and delete operators behave as if they
do not access global state (so if they do access global state then
they must do so safely.)  See [new.delete.dataraces] in C++11.

The new in libstdc++ just forwards to malloc, so whether that
requirement is met depends on your C library's malloc.

For GNU/Linux systems (and probably most others too) you don't need to
do anything special for malloc to be thread safe.

N.B. Currently calling std::set_new_handler concurrently with calls to
new or other calls to set_new_handler *does* introduce a data race.
This is a bug in libstdc++.

> 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.)

I can't think of a better solution than querying the compiler that
provided the library.  If the user has installed the compiler
themselves and replaced either the compiler executables or the
libraries then the answer might not be reliable.