Доступ к куче сериализуется?

new и delete равны потокобезопасный

The following functions are required to be thread-safe:

• The library versions of operator new and operator delete
• User replacement versions of global operator new and operator delete
• std::calloc, std::malloc, std::realloc, std::aligned_alloc, std::free

Calls to these functions that allocate or deallocate a particular unit of storage occur in a single total order, and each such deallocation call happens-before the next allocation (if any) in this order.

С gcc new реализуется путем делегирования malloc, и мы видим, что их malloc действительно выполняет использовать замок. Если вы беспокоитесь о том, что ваше распределение вызовет узкие места, напишите свой собственный распределитель.

Ответ положительный, но на практике как правило не проблема. Если это проблема для вас, вы можете попробовать заменить свою реализацию malloc на tcmalloc, что уменьшает, но не устраняет возможную конкуренцию (поскольку существует только 1 куча, которая должна быть разделена между потоками и процессами).

TCMalloc assigns each thread a thread-local cache. Small allocations are satisfied from the thread-local cache. Objects are moved from central data structures into a thread-local cache as needed, and periodic garbage collections are used to migrate memory back from a thread-local cache into the central data structures.

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

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

Первый ответ должен быть просто это зависит от реализации без каких-либо системных зависимостей, потому что обычно библиотеки получают большие куски памяти для создания кучи и управляют ими внутренне, что делает проблему фактически независимой от операционной системы и архитектуры.

Второй ответ заключается в том, что, конечно, если у вас есть только одна куча для всех потоков, у вас может возникнуть узкое место, если все активные потоки будут конкурировать за один кусок памяти. Есть несколько подходов к этому, вы можете иметь пул куч, чтобы обеспечить параллелизм, и заставить разные потоки использовать разные пулы для своих запросов, подумайте, что возможная самая большая проблема заключается в запросе памяти, как это бывает, когда у вас есть горлышко бутылки. При возврате такой проблемы нет, так как вы можете действовать больше как сборщик мусора, в котором вы ставите в очередь возвращенные фрагменты памяти и ставите их в очередь для отправки потока и помещаете эти фрагменты в нужные места для сохранения целостности кучи. Наличие нескольких куч позволяет даже классифицировать их по приоритетам, размерам фрагментов и т. д., поэтому риск коллизии снижается из-за класса или проблемы, с которой вы собираетесь иметь дело. Это относится к ядрам операционных систем, таким как *BSD, которые используют несколько куч памяти, отчасти выделенных для того вида использования, который они собираются получить (есть один для буферов io-disk, один для отображаемых сегментов виртуальной памяти, один для процесса). управление пространством виртуальной памяти и т. д.)

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