Является ли функция C ++ `free` поточно-ориентированной?

Question

То есть, если мое приложение C ++ выделяет память в одном потоке, используя malloc, free будет успешно де-выделять память, если вызывается из другого потока, или я могу ожидать, что оно вызовет исключение? Оба потока принадлежат одному процессу. Я использую Visual Studio 2008. Спасибо.

Answer 1

Текущий стандарт не дает никаких гарантий относительно потоков. В большинстве реализаций malloc и free могут вызываться из разных потоков. Код кучи Visual C ++ также сериализует доступ к кучам, так что все будет в порядке.

Answer 2

Если malloc и free правильно синхронизированы, освобождение памяти в другом потоке совершенно нормально и безопасно. Более того, это утверждение верно в соответствии со стандартом C ++ 0x. Как упоминалось в @Ashot, текущий стандарт C ++ 03 имеет дело только с моделью однопоточного исполнения

Answer 3

Текущий стандарт C ++ даже не знает о потоках.Так что с точки зрения стандарта я не думаю, что вы можете сказать, нормально это или нет.Однако все потоки в программе имеют одинаковое адресное пространство, поэтому для освобождения объекта в другом потоке должно быть нормально.

Answer 4

В этом смысле потокобезопасен (пул malloc является глобальным для процесса, а не локальным для потока), но не в смысле разумного поведения, если вызывается, когда другой поток вызывает malloc() или free().

Answer 5

Если компилятор C и ОС поддерживают потоки, тогда это будет безопасно.

Если ваш компилятор работает в Windows, вы должны убедиться, что вы связываетесь с многопоточными библиотеками времени выполнения.Или, если ваш компилятор поддерживает опцию -pthread или что-то подобное, он также безопасен.

Если у компилятора есть флаг, подобный -pthread, тогда не думайте, что все это потокобезопасно, если вы не используете этот флаг.Использование флага будет связывать разные библиотеки и устанавливать разные макросы препроцессора.Вполне возможно, что при задании этого флага будет связана совершенно другая поточно-безопасная среда выполнения C.