Administrar la duración de los objetos mediante el recuento de referencias

  • Artículo

En los sistemas de objetos tradicionales, el ciclo de vida de los objetos (es decir, los problemas relacionados con la creación y eliminación de objetos) se controlan implícitamente por el lenguaje (o el tiempo de ejecución del lenguaje) o explícitamente por los programadores de aplicaciones.

En una evolución, el sistema construido de forma centralizada formado por componentes reutilizados, ya no es cierto que ningún cliente, o incluso cualquier programador, siempre "sabe" cómo tratar con la duración de un componente. Para un cliente con los privilegios de seguridad adecuados, sigue siendo relativamente fácil crear objetos a través de una solicitud simple, pero la eliminación de objetos es otra cuestión completamente. No es necesariamente claro cuando ya no se necesita un objeto y se debe eliminar. (Los lectores familiarizados con los entornos de programación recopilados por elementos no utilizados, como Java, pueden no estar de acuerdo; sin embargo, los objetos Java no abarcan los límites de la máquina o incluso los límites del proceso y, por lo tanto, la recolección de elementos no utilizados está restringida a objetos que viven dentro de un espacio de proceso único. Además, Java fuerza el uso de un único lenguaje de programación). Incluso cuando el cliente original se realiza con el objeto , simplemente no puede apagar el objeto, ya que algún otro cliente o cliente podría seguir teniendo una referencia a él.

Una manera de asegurarse de que un objeto ya no es necesario es depender completamente de un canal de comunicación subyacente para informar al sistema cuando todas las conexiones a un objeto entre procesos o entre canales han desaparecido. Sin embargo, los esquemas que usan este método son inaceptables por varias razones. Un problema es que podría requerir una diferencia importante entre el modelo de programación entre procesos y entre redes y el modelo de programación de un solo proceso. En el modelo de programación entre procesos y entre redes, el sistema de comunicación proporcionaría los enlaces necesarios para la administración de la duración de los objetos, mientras que en el modelo de programación de un solo proceso, los objetos se conectan directamente sin ningún canal de comunicación intermedio. Otro problema es que este esquema también podría dar lugar a una capa de software proporcionado por el sistema que interferiría con el rendimiento de los componentes en el caso en proceso. Además, un mecanismo basado en la supervisión explícita no tiende a escalarse hacia muchos miles o millones de objetos.

COM ofrece un enfoque escalable y distribuido para este conjunto de problemas. Los clientes indican a un objeto cuándo lo usan y cuándo se realizan, y los objetos se eliminan cuando ya no son necesarios. Este enfoque exige que todos los objetos cuentan referencias a sí mismos. Los lenguajes de programación como Java, que tienen de forma inherente sus propios esquemas de administración de duración, como la recolección de elementos no utilizados, pueden usar el recuento de referencias de COM para implementar y usar objetos COM internamente, lo que permite al programador evitar tratar con él.

Al igual que una aplicación debe liberar memoria que ha asignado una vez que esa memoria ya no está en uso, un cliente de un objeto es responsable de liberar sus referencias al objeto cuando ese objeto ya no es necesario. En un sistema orientado a objetos, el cliente solo puede hacerlo proporcionando al objeto una instrucción para liberarse.

Es importante que un objeto se desasigne cuando ya no se use. La dificultad consiste en determinar cuándo es adecuado desasignar un objeto. Esto es fácil con las variables automáticas (las asignadas en la pila): no se pueden usar fuera del bloque en el que se declaran, por lo que el compilador los desasigna cuando se alcanza el final del bloque. En el caso de los objetos COM, que se asignan dinámicamente, corresponde a los clientes de un objeto decidir cuándo ya no necesitan usar el objeto, especialmente objetos locales o remotos que pueden estar en uso por varios clientes al mismo tiempo. El objeto debe esperar hasta que todos los clientes terminen con él antes de liberarse. Dado que los objetos COM se manipulan a través de punteros de interfaz y los pueden usar objetos en procesos diferentes o en otras máquinas, el sistema no puede realizar un seguimiento de los clientes de un objeto.

El método de COM para determinar cuándo es adecuado desasignar un objeto es el recuento manual de referencias. Cada objeto mantiene un recuento de referencias que realiza un seguimiento del número de clientes conectados a él, es decir, cuántos punteros existen en cualquiera de sus interfaces en cualquier cliente.

Para obtener más información, vea los temas siguientes:

Uso e implementación de IUnknown