¿Malloc es seguro para subprocesos?
multithreading thread-safety (10)
Aquí hay un extracto de malloc.c de glibc:
Seguridad de subprocesos: seguro para subprocesos a menos que NO_THREADS esté definido
suponiendo que NO_THREADS no está definido por defecto, malloc es seguro para subprocesos al menos en Linux.
Es la función malloc() reentrante?
Depende de qué implementación de la biblioteca C runtime esté usando. Si está utilizando MSVC, por ejemplo, hay una opción de compilación que le permite especificar con qué versión de la biblioteca desea construir (es decir, una biblioteca en tiempo de ejecución que admite multi-threading porque es seguro para la banda de rodadura o no).
Esta es una pregunta bastante antigua y quiero aportar frescura según el estado actual de las cosas.
Sí, actualmente malloc() es seguro para subprocesos.
Del Manual de referencia de la Biblioteca GNU C de glibc-2.20 [released 2014-09-07] :
void * malloc (size_t size)Preliminar: MT-Safe | ...
... 1.2.2.1 Conceptos de seguridad POSIX:
... Las funciones MT-Safe o Thread-Safe son seguras para llamar en presencia de otros hilos. MT, en MT-Safe, significa Multi Thread.
Ser MT-Safe no implica que una función sea atómica, ni que utilice ninguno de los mecanismos de sincronización de memoria que POSIX expone a los usuarios. Incluso es posible que llamar a las funciones MT-Safe en secuencia no proporcione una combinación MT-Safe. Por ejemplo, tener un hilo que llame a dos funciones de MT-Safe, una después de la otra, no garantiza un comportamiento equivalente a la ejecución atómica de una combinación de ambas funciones, ya que las llamadas simultáneas en otros hilos pueden interferir de forma destructiva.
Las optimizaciones de todo el programa que podrían alinear funciones en las interfaces de la biblioteca pueden exponer el reordenamiento inseguro, por lo que no se recomienda realizar la alineación en la interfaz de la Biblioteca GNU C. El estado documentado de MT-Safety no está garantizado en la optimización de un programa completo. Sin embargo, las funciones definidas en los encabezados visibles para el usuario están diseñadas para ser seguras para la alineación.
Leí en alguna parte que si compila con -pthread, malloc se convierte en hilo seguro. Sin embargo, estoy bastante seguro de que su implementación depende, ya que malloc es ANSI C y los hilos no lo son.
Si estamos hablando de gcc:
Compilar y vincular con -pthread y malloc () será seguro para subprocesos, en x86 y AMD64.
Otra opinión, más perspicaz
{malloc, calloc, realloc, free, posix_memalign} de glibc-2.2 + son seguros para subprocesos
http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.apps/2005-07/0323.html
No, no es seguro para subprocesos. En realidad, puede haber una función malloc_lock() y malloc_unlock() disponible en su biblioteca C. Sé que existen para la biblioteca Newlib. Tuve que usar esto para implementar un mutex para mi procesador, que tiene múltiples subprocesos en el hardware.
Pregunta: "¿Malloc reentrant"?
Respuesta: no, no lo es. Aquí hay una definición de lo que hace una reentrant rutina.
Ninguna de las versiones comunes de malloc le permite volver a ingresarla (por ejemplo, desde un manejador de señal). Tenga en cuenta que una rutina reentrante puede no usar bloqueos, y casi todas las versiones malloc existentes usan bloqueos (que los hacen seguros para subprocesos) o variables globales / estáticas (lo que los hace inseguros y no reentrantes).
Todas las respuestas hasta ahora responden "¿Malloc thread-safe?", Que es una pregunta completamente diferente. Para esa pregunta, la respuesta es que depende de la biblioteca de tiempo de ejecución y posiblemente de los indicadores del compilador que utilice. En cualquier UNIX moderno, obtendrá un malloc seguro para subprocesos de forma predeterminada. En Windows, use los /MTd /MT , /MTd , /MD o /MDd para obtener una biblioteca de tiempo de ejecución segura para subprocesos.
Sí, bajo POSIX.1-2008 malloc es seguro para subprocesos.
2.9.1 Seguridad de subprocesos
Todas las funciones definidas por este volumen de POSIX.1-2008 deben ser seguras para hilos, excepto que las siguientes funciones1 no necesitan ser seguras para subprocesos.
[una lista de funciones que no contiene
malloc]
Si está trabajando con GLIBC, la respuesta es: Sí, PERO.
Específicamente, sí, PERO, tenga en cuenta que, aunque malloc y free son seguros para subprocesos, las funciones de depuración no lo son.
Específicamente, las funciones extremadamente útiles mtrace (), mcheck () y mprobe () no son seguras para subprocesos . En una de las respuestas más cortas y directas que verás en un proyecto de GNU, esto se explica aquí:
https://sourceware.org/bugzilla/show_bug.cgi?id=9939
Deberá considerar técnicas alternativas, como ElectricFence, valgrind, dmalloc, etc.
Entonces, si quiere decir, "son las funciones malloc () y free () encastrables", la respuesta es sí. Pero si te refieres a "es la totalidad de la suite malloc / free threadsafe", la respuesta es NO.
malloc y free no son reentrantes, porque usan una estructura de datos estática que registra qué bloques de memoria son libres. Como resultado, no se reentratan funciones de biblioteca que asignan o liberan memoria.