Gestión de recursos (informática)

Formalmente, la gestión de recursos (prevención de fugas de recursos) consiste en asegurar que un recurso se libere si y solo si se adquiere con éxito. Este problema general se puede abstraer como código " antes, cuerpo y después ", que normalmente se ejecuta en este orden, con la condición de que el código después se llama si y solo si el código antes se completa con éxito, independientemente de si el código cuerpo se ejecuta con éxito o no. Esto también se conoce como ejecución alrededor ^{[ 1 ]} o un sándwich de código, y ocurre en varios otros contextos, ^{[ 2 ]} como un cambio temporal de estado del programa, o el rastreo de entrada y salida en una subrutina . Sin embargo, la gestión de recursos es la aplicación más citada. En la programación orientada a aspectos , dicha lógica de ejecución alrededor es una forma de consejo .

En la terminología del análisis del flujo de control , la liberación de recursos debe ser posterior a la adquisición exitosa de recursos; ^{[ 3 ]} no garantizar esto es un error, y una ruta de código que viola esta condición causa una fuga de recursos. Las fugas de recursos suelen ser problemas menores, que generalmente no bloquean el programa, sino que causan cierta ralentización del programa o del sistema en general. ^{[ 2 ]} Sin embargo, pueden causar bloqueos, ya sea del propio programa o de otros programas, debido al agotamiento de recursos: si el sistema se queda sin recursos, las solicitudes de adquisición fallan. Esto puede presentar un fallo de seguridad si un ataque puede causar el agotamiento de recursos. Las fugas de recursos pueden ocurrir durante el flujo normal del programa, como simplemente olvidar liberar un recurso, o solo en circunstancias excepcionales, como cuando un recurso no se libera si hay una excepción en otra parte del programa. Las fugas de recursos son causadas con mucha frecuencia por la salida anticipada de una subrutina, ya sea por una returninstrucción o por una excepción generada por la propia subrutina o por una subrutina más profunda a la que llama. Si bien la liberación de recursos debido a las instrucciones de retorno se puede manejar liberándolos cuidadosamente dentro de la subrutina antes del retorno, las excepciones no se pueden manejar sin alguna facilidad de lenguaje adicional que garantice que se ejecute el código de liberación.

De forma más sutil, la adquisición exitosa de recursos debe dominar la liberación de recursos, ya que de lo contrario el código intentará liberar un recurso que no ha adquirido. Las consecuencias de una liberación incorrecta de este tipo van desde ser ignorada silenciosamente hasta el bloqueo del programa o un comportamiento impredecible. Estos errores generalmente se manifiestan raramente, ya que requieren que la asignación de recursos falle primero, lo cual suele ser un caso excepcional. Además, las consecuencias pueden no ser graves, ya que el programa puede estar fallando debido a la imposibilidad de adquirir un recurso esencial. Sin embargo, estos errores pueden impedir la recuperación del fallo o convertir un cierre ordenado en uno desordenado. Esta condición generalmente se garantiza verificando primero que el recurso se haya adquirido correctamente antes de liberarlo, ya sea mediante una variable booleana que registre "adquirido correctamente" (lo cual carece de atomicidad si el recurso se adquiere pero la variable de indicador no se actualiza, o viceversa) o mediante el identificador del recurso de un tipo anulable , donde "nulo" indica "no adquirido correctamente", lo que garantiza la atomicidad.

En informática, la contención de recursos se refiere a un conflicto que surge cuando varias entidades intentan acceder a un recurso compartido, como la memoria de acceso aleatorio, el almacenamiento en disco, la memoria caché, los buses internos o los dispositivos de red externos.

El enfoque más común para la gestión de recursos en distintos lenguajes es el uso de la protección de desenrollado, que se llama cuando la ejecución sale de un ámbito, ya sea porque la ejecución sale del bloque, regresa desde dentro del bloque o se lanza una excepción. Esto funciona para recursos gestionados por pila y está implementado en muchos lenguajes, incluidos C#, Common Lisp, Java, Python, Ruby y Scheme. Los principales problemas de este enfoque son que el código de liberación (generalmente en una finallycláusula) puede estar muy alejado del código de adquisición (carece de adyacencia ) y que el código de adquisición y liberación siempre debe estar emparejado por quien lo llama (carece de encapsulación ). Esto se puede solucionar funcionalmente, usando cierres/devoluciones de llamada/corutinas (Common Lisp, Ruby, Scheme), o usando un objeto que gestione tanto la adquisición como la liberación, y añadiendo una construcción del lenguaje para llamar a estos métodos cuando el control entra y sale de un ámbito (C# using, Java trycon recursos, Python with); véase más abajo.

Un enfoque alternativo, más imperativo, es escribir código asíncrono en estilo directo : adquirir un recurso y luego en la siguiente línea tener una liberación diferida , que se llama cuando se sale del ámbito – adquisición síncrona seguida de liberación asíncrona. Esto se originó en C++ como la clase ScopeGuard, por Andrei Alexandrescu y Petru Marginean en 2000, ^{[ 4 ]} con mejoras de Joshua Lehrer, ^{[ 5 ]} y tiene soporte directo del lenguaje en D a través de la scopepalabra clave ( ScopeGuardStatement ), donde es un enfoque para la seguridad de excepciones , además de RAII (ver más abajo). ^{[ 6 ]} También se ha incluido en Go, como la deferinstrucción. ^{[ 7 ]} Este enfoque carece de encapsulación – uno debe hacer coincidir explícitamente la adquisición y la liberación – pero evita tener que crear un objeto para cada recurso (en términos de código, evitar escribir una clase para cada tipo de recurso).

En la programación orientada a objetos , los recursos se encapsulan dentro de los objetos que los utilizan, como por ejemplo un fileobjeto con un campo cuyo valor es un descriptor de archivo (o, más generalmente, un identificador de archivo ). Esto permite que el objeto utilice y gestione el recurso sin que los usuarios del objeto tengan que hacerlo. Sin embargo, existen diversas formas en que los objetos y los recursos pueden relacionarse.

En primer lugar, está la cuestión de la propiedad: ¿ tiene un objeto un recurso?

• Los objetos pueden poseer recursos (a través de la composición de objetos , una fuerte relación de "tiene un").
• Los objetos pueden ver recursos (a través de la agregación de objetos , una relación débil de "tiene un").
• Los objetos pueden comunicarse con otros objetos que tengan recursos (a través de la asociación ).

Los objetos que poseen un recurso pueden adquirirlo y liberarlo de diferentes maneras, en diferentes momentos durante la vida útil del objeto ; estos ocurren en pares, pero en la práctica a menudo no se utilizan de forma simétrica (véase más abajo):

• Adquirir/liberar mientras el objeto sea válido, mediante métodos (de instancia) como openo dispose.
• Adquirir/liberar durante la creación/destrucción de objetos (en el inicializador y el finalizador).
• Ni se adquiere ni se libera el recurso, sino que simplemente se tiene una vista o referencia a un recurso gestionado externamente al objeto, como en la inyección de dependencias ; concretamente, un objeto que tiene un recurso (o puede comunicarse con uno que lo tiene) se pasa como argumento a un método o constructor.

Lo más habitual es adquirir un recurso durante la creación del objeto y liberarlo explícitamente mediante un método de instancia, comúnmente llamado `dispose` dispose. Esto es análogo a la gestión de archivos tradicional (adquirir durante la creación del objeto openy liberarlo explícitamente close), y se conoce como el patrón `dispose` . Este es el enfoque básico utilizado en varios lenguajes modernos de programación orientada a objetos, como Java , C# y Python , y estos lenguajes cuentan con construcciones adicionales para automatizar la gestión de recursos. Sin embargo, incluso en estos lenguajes, las relaciones entre objetos más complejas dan lugar a una gestión de recursos más compleja, como se explica más adelante.

try ( BufferedReader reader = new BufferedReader ( new InputStreamReader ( new FileInputStream ( fileName )))) { // Usar el lector. } // El lector se cierra cuando se sale del bloque try-with-resources, que cierra cada uno de los objetos contenidos en secuencia.

try ( FileInputStream stream = new FileInputStream ( fileName )))) { BufferedReader reader = new BufferedReader ( new InputStreamReader ( stream )); // Usar reader. } // stream se cierra cuando se sale del bloque try-with-resources. // reader ya no se puede usar después de que stream se cierra, pero siempre que no escape del bloque, esto no es un problema.

importar csv desde typing importar iteradorcon open ( filename ) como f : r : Iterator [ list [ str ]] = csv . reader ( f ) # Usar r. # f se cierra cuando se sale de la instrucción with y ya no se puede usar. # No se hace nada con r, pero el f subyacente se cierra, por lo que r tampoco se puede usar.

En la programación estructurada , la gestión de recursos de la pila se realiza simplemente anidando el código lo suficiente para manejar todos los casos. Esto requiere solo un único retorno al final del código y puede resultar en un código muy anidado si se deben adquirir muchos recursos, lo que algunos consideran un antipatrón : el antipatrón de la flecha ^{[ 10 ],} debido a la forma triangular que adquiere el anidamiento sucesivo.

Otro enfoque, que permite una salida temprana pero centraliza la limpieza en un solo lugar, consiste en tener una única instrucción `out` de la función, precedida por el código de limpieza, y usar `goto` para saltar a la limpieza antes de la salida. Esto se ve con poca frecuencia en el código moderno, pero ocurre en algunos usos de C.