new и delete обрабатывают проблемы многопоточности

Question

Я читаю книгу Эффективный C ++: методы программирования производительности Авторы говорят следующее относительно глобальных операторов new и delete:

Они управляют памятью в контексте процесса, и поскольку процесс может порождает несколько потоков, new() и delete() должны иметь возможность работать в многопоточная среда. Кроме того, размер запросов памяти может варьироваться от одного запроса к другому.

in Глава 6. Пул однопоточной памяти .

Это правда? Я думал, что в C ++ нет понятия Многопоточная среда , программисту нужно работать с помощью некоторых средств взаимного исключения.

Answer 1

Это будет зависеть от реализации. Например, среда выполнения Visual C ++ имела как однопоточную, так и многопоточную версию кучи в более ранней версии, но начиная с Visual C ++ 2005 она имеет только многопоточную версию. В этой статье MSDN есть хорошая сводная таблица.

Когда используется многопоточная куча, вызовы выделения и освобождения памяти являются поточно-ориентированными за счет дополнительных накладных расходов.

Answer 2

C ++ (стандарт C ++ 03) не говорит о многопоточности. Однако большинство платформ поддерживают поточно-ориентированный new/malloc. Вот предыдущий пост , обсуждающий такой же вопрос.

В C ++ 11 представлены потоки.

Answer 3

Начиная с C ++ 11 (который имеет концепцию гонки данных), стандарт гарантирует, что new/delete, calloc/malloc/realloc/free будет происходить в едином общем порядке.

Начиная с n3690 18.6.1.4:

В целях определения существования гонок данных, библиотечных версий оператора new, пользовательских заменяющих версий глобального оператора new, стандартных библиотечных функций C calloc и malloc, библиотечных версий оператора delete,заменяемые пользователем версии оператора delete, функции стандартной библиотеки C free и функции realloc стандартной библиотеки C не должны вводить гонку данных (17.6.5.9).Вызовы этих функций, которые выделяют или освобождают определенную единицу хранения, должны происходить в едином общем порядке, и каждый такой вызов освобождения должен происходить до (1.10) следующего выделения (если есть) в этом порядке.

Я не смог найти таких гарантий в предыдущих версиях стандарта, но (как уже говорили другие), я полагаю, что большинство реализаций обеспечивают многопоточную поддержку выделения памяти.