En informática, un programa informático o subrutina se llama reentrante si puede ser interrumpido en medio de su ejecución y volver a llamarse de forma segura ("re-entrar") antes de que las invocaciones anteriores completen su ejecución. La interrupción puede ser causada por una acción interna como un salto o llamada, o por una acción externa como una interrupción o señal. Una vez que la invocación re-entrante completa, las invocaciones anteriores reanudarán su ejecución de forma correcta.
Esta definición se origina en los entornos de un único subproceso de programación en el que el flujo de control podría ser interrumpido por una alarma de proceso y se transfiere a una rutina de servicio de interrupción (ISR). Cualquier subrutina utilizada por el ISR que podría potencialmente se han ejecutado cuando la alarma se activó debe ser de reentrada. A menudo, las subrutinas accesibles a través del sistema operativo del kernel no son reentrantes. Por lo tanto, las rutinas de servicio de interrupción son limitados en las acciones que pueden realizar; por ejemplo, que suelen limitarse el acceso al sistema de archivos y, a veces incluso de asignar memoria.
Una subrutina que es directa o indirectamente recursiva debe ser de reentrada. Esta directiva se aplica parcialmente por los Lenguajes de programación estructurados. Sin embargo una subrutina puede dejar de ser reentrante si se basa en una variable global a permanecer sin cambios, pero esa variable se modifica cuando se invoca recursivamente la subrutina.
Esta definición de reentrada difiere de la de hilo de seguridad en entornos multi-hilo. Una subrutina reentrada puede lograr hilo de seguridad, pero al ser de reentrada por sí solo podría no ser suficiente para ser flujos seguros en todas las situaciones. Por el contrario, el código flujos seguros no necesariamente tiene que ser de reentrada (ver más abajo para los ejemplos).
Otros términos utilizados para los programas de reentrada incluyen "procedimiento puro" o "código compartible".
Este es un ejemplo de un swap() función que no sea reentrante (así como dejar de ser seguro para subprocesos). Como tal, no debería haber sido utilizado en el servicio de interrupción rutina isr():
swap() podría hacerse flujos seguros al hacer t hilo local . Se sigue sin ser de reentrada, y esto seguirá causando problemas si isr() es llamado en el mismo contexto que un hilo ya la ejecución de swap().
La siguiente (un tanto artificial) la modificación de la función de intercambio, que es cuidado de dejar los datos globales en un estado coherente en el momento de que salga, es perfectamente reentrada; Sin embargo, no es seguro para subprocesos, ya que no garantiza los datos globales se encuentra en un estado coherente durante la ejecución:
Reentrada no es la misma cosa que idempotencia, en el que la función puede ser llamado más de una vez todavía generar exactamente la misma salida que si sólo había sido llamado una vez. En términos generales, una función produce datos de salida sobre la base de unos datos de entrada (aunque ambos son opcionales, en general). Los datos compartidos se podía acceder por cualquier persona en cualquier momento. Si los datos se pueden cambiar por nadie (y nadie hace un seguimiento de los cambios), entonces no hay ninguna garantía para los que comparten un dato si ese dato es el mismo que en cualquier momento antes.
Datos tiene una característica llamada alcance, que describe donde en un programa se pueden usar los datos. Ámbito de aplicación de datos es ya sea global (fuera del alcance de cualquier función y con una indefinida medida}, o locales (creado cada vez que una función se llama y destruyó a la salida).
Los datos locales no son compartidas por los hubiere, de volver a entrar o no, las rutinas; por lo tanto, no afectan a re-entrada. Los datos globales se definen las funciones externas, y se puede acceder a más de una función, ya sea en forma de variable global (datos compartidos entre todas las funciones), o como variable estática (datos compartidos por todas las funciones del mismo nombre). En la programación orientada a objetos, datos globales se definen en el alcance de una clase y pueden ser privadas, por lo que es accesible sólo a las funciones de esa clase. También existe el concepto de variable de instancia, en una variable de clase está obligado a una instancia de clase. Por estas razones, en la programación orientada a objetos de esta distinción es generalmente reservado para los datos de acceso situados fuera de la clase (público), y por el independiente los datos de las instancias de clase (estática).
Reentrada es distinto de, pero estrechamente relacionado con, hilo de seguridad. Una función puede ser seguro para subprocesos y todavía no reentrante. Por ejemplo, una función podría ser envuelto por todas partes con un mutex (que evita problemas en entornos multiproceso), pero si esa función se usa en una rutina de servicio de interrupción, podría morir de hambre a la espera de la primera ejecución para liberar el mutex. La clave para evitar la confusión es que reentrada se refiere a un solo hilo de ejecución. Es un concepto desde el momento cuando no existían sistemas operativos multitarea.
Un "controlador de interrupciones de reentrada" es un manejador de interrupciones que vuelve a habilitar las interrupciones temprano en el manejador de interrupciones. Esto puede reducir la latencia de interrupción. En general, mientras que las rutinas de servicio de interrupción de programación, se recomienda volver a habilitar las interrupciones tan pronto como sea posible en el manejador de interrupciones. Esta práctica ayuda a evitar la pérdida de las interrupciones.
En el siguiente fragmento de código C, ni f ni g funciones son reentrantes.
En lo anterior, f depende de un no constante variable global g_var; por lo tanto, si dos hilos de ejecutarlo y acceso g_var simultáneamente, el resultado varía dependiendo del momento de la ejecución. Por lo tanto, f no es reentrante. Tampoco es g; que llama f, que no es reentrante.
Estas versiones ligeramente alterados son reentrantes:
En el siguiente fragmento de código C, la función es seguro para subprocesos, pero no por reentrada.
En lo anterior, function puede ser llamado por diferentes hilos sin ningún problema. Pero si la función se usa en un manejador de interrupciones reentrante y una segunda interrupción surge dentro de la función, la segunda rutina se colgará para siempre. Como servicio de interrupción puede desactivar otras interrupciones, todo el sistema podría sufrir.
Escribe un comentario o lo que quieras sobre Reentrancia (informática) (directo, no tienes que registrarte)
Comentarios
(de más nuevos a más antiguos)