Подтвердить что ты не робот

В С++ может ли новый в одном потоке выделить память, удаленную другим потоком?

В glibc malloc реализуется с арены. Так, например, возможно, что память, сначала выделенная malloc, а затем free d в потоке A, не может использоваться другим вызовом malloc в потоке B, поскольку потоки A и B могут быть в разных арены и разные арены поддерживают разные кучи и свободные списки памяти.

Когда дело доходит до С++ (возможно, также С++ 11, поскольку С++ 11 имеет новый стандарт), история остается прежней?

Или разные потоки фактически разделяют один и тот же сегмент кучи и свободный список памяти, а new в одном потоке могут выделять память сначала new ed, а затем delete d другим потоком?

Если ответ зависит от реализации, тогда возникает вопрос, каким образом они реализуются в основных компиляторах С++, таких как g++, MVС++, icc?

ИЗМЕНИТЬ

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

4b9b3361

Ответ 1

Это:

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

Назначение потоков - совместное использование пространства памяти. Если вам не нужна эта функция, вам лучше использовать процессы.

Ответ 2

С++ std и реализация распределителя, которые вы используете, - это две разные вещи. Если вы используете gcc для компиляции кода на С++, он по умолчанию использует glibc в качестве распределителя. Поэтому, если ваш gcc является достаточно новой версией, он использует glibc с аренами для каждой нити, и вам хорошо идти.

Ответ 3

Это зависит. В Windows потоку, который использует DLL, не разрешается передавать права собственности на память, размещенные в одной DLL, в другую DLL. Все новости и удаления должны выполняться на "той же стороне" библиотеки DLL. Хотя это не является строгой проблемой нити, она по-прежнему подразумевает, что поток не может просто передать владение памятью в любой другой поток, не зная, откуда возникла память.

Смотрите Do (статически связанные) DLL используют другую кучу, чем основная программа?