reentrante no se basan en variables globales que se exponen en las cabeceras de la biblioteca de C .. tomar strtok() vs strtok_r (por ejemplo) en C.
Algunas funciones necesitan un lugar para almacenar un ' work in progress ', las funciones de reentrante le permiten especificar este puntero dentro del propio almacenamiento del subproceso, no en un global. Como este almacenamiento es exclusivo de la función de llamada, puede interrumpirse y reingresar (reingreso) y dado que en la mayoría de los casos la exclusión mutua más allá de lo que la función implementa no es necesaria para que funcione, a menudo se consideran ser hilo seguro. Sin embargo, esto no está garantizado por definición.
errno, sin embargo, es un caso ligeramente diferente en sistemas POSIX (y tiende a ser la excéntrica en cualquier explicación de cómo funciona todo esto) :)
En resumen, reentrante menudo significa hilo de seguridad (como en "use la versión reentrante de esa función si está utilizando subprocesos"), pero la seguridad de subprocesos no siempre significa volver a entrar (o al revés). Cuando mira la seguridad de hilo, concurrencia es lo que debe tener en cuenta. Si tiene que proporcionar un medio de bloqueo y exclusión mutua para usar una función, entonces la función no es intrínsecamente segura para subprocesos.
Pero no es necesario examinar todas las funciones. malloc()
no necesita ser reentratado, no depende de nada fuera del alcance del punto de entrada para un hilo determinado (y es en sí mismo seguro para subprocesos).
Las funciones que devuelven valores asignados estáticamente son no hilo seguro sin el uso de un mutex, futex u otro mecanismo de bloqueo atómico. Sin embargo, no necesitan ser reentrantes si no van a ser interrumpidos.
es decir .:
static char *foo(unsigned int flags)
{
static char ret[2] = { 0 };
if (flags & FOO_BAR)
ret[0] = 'c';
else if (flags & BAR_FOO)
ret[0] = 'd';
else
ret[0] = 'e';
ret[1] = 'A';
return ret;
}
Por lo tanto, como se puede ver, que tienen múltiples hilos de usar que sin algún tipo de bloqueo sería un desastre .. pero no tiene el propósito de ser re-entrante. Se encontrará con eso cuando la memoria asignada dinámicamente es tabú en alguna plataforma incorporada.
En la programación puramente funcional, reentrante menudo no implica hilo de seguridad, que dependerá del comportamiento de las funciones definidas o anónimos pasados al punto de entrada de la función, la recursión, etc.
Una mejor manera de poner 'hilo seguro' es seguro para acceso concurrente, que ilustra mejor la necesidad.
reentrante no implica thread-safe. Las funciones puras implican seguridad de hilo. –
Gran respuesta Tim. Solo para aclarar, mi comprensión de su "a menudo" es que la seguridad de subprocesos no implica reentrada, pero también reentrada no implica seguro de subprocesos. ¿Sería capaz de encontrar un ejemplo de una función de reentrada que * no * es segura para subprocesos? – Riccardo
@ Tim Post "En resumen, reentrante a menudo significa hilo seguro (como en" usar la versión reentrante de esa función si estás utilizando subprocesos "), pero seguro de subprocesos no siempre significa volver a entrar". qt [dice] (http://qt-project.org/doc/qt-4.8/threads-reentrancy.html) al revés: "Por lo tanto, una función de hilo seguro siempre es reentrante, pero una función de reentrada no siempre es un hilo seguro." – 4pie0