New and deleted multithreading descriptors

Question

I am reading Efficient C ++: Performance Programming Techniques. The authors say the following about global new and remote operators:

They manage memory in the context of a process, and since a process can create multiple threads, new() and delete() should work in a multi-threaded environment. In addition, the size of memory requests can vary from one request to the next.

in chapter 6. Combining single-threaded memory.

It's true? I thought that C ++ did not have the concept of a multi-threaded environment, the programmer should cope with using some methods of mutual exclusion.

Answer 1

It will be implementation dependent. For example, the Visual C ++ runtime had both a single-threaded and multi-threaded version of the heap in an earlier version, but since Visual C ++ 2005 it has only a multi-threaded version. This MSDN article has a good pivot table.

When a multi-threaded heap is used, calls to allocate and free memory are thread safe due to the additional overhead.

Answer 2

C ++ (C ++ 03 standard) does not talk about multithreading. However, most platforms support new/malloc thread safety. Here is a previous post discussing the same issue.

In C ++ 11, streams are introduced.

Answer 3

As in C ++ 11 (which has the concept of data race), the standard ensures that new/delete , calloc/malloc/realloc/free will happen in one complete order.

From n3690 18.6.1.4:

In order to determine the existence of a data race, the version of the operator library new, the user-defined version of the global operator new, the standard library functions C calloc and malloc, the library versions of the operator deletion, the versions of the user replacements to delete the operator, the function of the standard library C and the standard library function C must enter data races (17.6.5.9). Calls to these functions that allocate or free a specific storage unit must be made in the same general order, and each such release call must occur before (1.10) the next distribution (if any) in that order.

I could not find such guarantees in previous versions of the standard, but (as others said). I believe that most implementations provide multi-threaded support for memory allocation.