C++ new operator thread safety in linux and gcc 4

Question

Soon i'll start working on a parallel version of a mesh refinement algorithm using shared memory.

A professor at the university pointed out that we have to be very careful about thread safety because neither the compiler nor the stl is thread aware.

I searched for this question and the answer depended on the compiler (some try to be somewhat thread-aware) and the plattform (if the system calls used by the compiler are thread-safe or not).

So, in linux, the gcc 4 compiler produces thread-safe code for the new operator?

If not, what is the best way to overcome this problem? Maybe lock each call to the new operator?

Answer 1

Generally the new operator is thread safe - however thread safety guarantees for calls into the STL and the standard library are governed by the standard - this doesn't mean that they are thread unaware - they tend to have very well defined guarantees of thread safety for certain operations. For example iterating through a list in a read-only fashion is thread safe for multiple readers, while iterating through a list and making updates is not. You have to read the documentation and see what the various guarantees are, although they aren't that onerous and they tend to make sense.

Answer 2

While I'm talking about concepts I have not used, I feel I should mention that if you're using shared memory, then you likely want to ensure that you use only POD types, and to use placement new.

Secondly, if you're using shared memory as it is commonly understood to be on linux systems, then you may be using multiple processes - not threads, to allocate memory and 'do stuff' - using shared memory as a communication layer. If this is the case, then the thread safety of your application and libraries are not important - what is important, however, is the thread safety of anything using the shared memory allocation! This is a different situation than running one process with many threads, in which case asking about the thread safety of the new operator IS a valid concern, and could be addressed by placement new if it is not, or by defining your own allocators.

Answer 3

You will have to look very hard to find a platform that supports threads but doesn't have a thread safe new. In fact, the thread safety of new (and malloc) is one of the reasons it's so slow.

If you want a thread safe STL on the other hand, you may consider Intel TBB which has thread aware containers (although not all operations on them are thread safe).

Answer 4

Hi,

Well, this is not a definitive answer to my question, just that I found out that Google implemented a high-performance multi-threaded malloc.

So, if you're in doubt of whether your implementation is thread safe, maybe you should use the Google Performance Tools.