Partager via

Gestion des durées de vie des objets via le comptage des références

  • Article

Dans les systèmes d’objets traditionnels, le cycle de vie des objets, c’est-à-dire les problèmes liés à la création et à la suppression d’objets, est géré implicitement par le langage (ou le temps d’exécution du langage) ou explicitement par les programmeurs d’application.

Dans un système évolutif, construit de manière décentralisée composé de composants réutilisés, il n’est plus vrai qu’un client, ou même un programmeur, « sait » toujours comment gérer la durée de vie d’un composant. Pour un client disposant des privilèges de sécurité appropriés, il est toujours relativement facile de créer des objets par le biais d’une simple requête, mais la suppression d’objet est une autre affaire. Il n’est pas nécessairement clair quand un objet n’est plus nécessaire et doit être supprimé. (Les lecteurs familiarisés avec les environnements de programmation garbage-collected, tels que Java, peuvent ne pas être d’accord; toutefois, les objets Java ne couvrent pas les limites de l’ordinateur ou même du processus, et par conséquent, le garbage collection est limité aux objets vivant dans un espace à processus unique. En outre, Java force l’utilisation d’un seul langage de programmation.) Même lorsque le client d’origine est terminé avec l’objet, il ne peut pas simplement arrêter l’objet, car un ou plusieurs autres clients peuvent toujours avoir une référence à celui-ci.

Une façon de s’assurer qu’un objet n’est plus nécessaire consiste à dépendre entièrement d’un canal de communication sous-jacent pour informer le système lorsque toutes les connexions à un objet interprocessus ou multicanal ont disparu. Toutefois, les schémas qui utilisent cette méthode sont inacceptables pour plusieurs raisons. L’un des problèmes est qu’il peut nécessiter une différence majeure entre le modèle de programmation inter-processus/réseau et le modèle de programmation à processus unique. Dans le modèle de programmation inter-processus/inter-réseaux, le système de communication fournit les crochets nécessaires à la gestion de la durée de vie des objets, tandis que dans le modèle de programmation à processus unique, les objets sont directement connectés sans canal de communication intervenant. Un autre problème est que ce schéma peut également entraîner une couche de logiciels fournis par le système qui interférerait avec les performances des composants dans le cas en cours de traitement. En outre, un mécanisme basé sur une surveillance explicite n’aurait pas tendance à être mis à l’échelle vers des milliers ou des millions d’objets.

COM offre une approche évolutive et distribuée de cet ensemble de problèmes. Les clients indiquent à un objet quand ils l’utilisent et quand ils sont terminés, et les objets se suppriment eux-mêmes lorsqu’ils ne sont plus nécessaires. Cette approche exige que tous les objets comptent les références à eux-mêmes. Les langages de programmation tels que Java, qui ont par nature leurs propres schémas de gestion de la durée de vie, tels que le garbage collection, peuvent utiliser le comptage des références de COM pour implémenter et utiliser des objets COM en interne, ce qui permet au programmeur d’éviter d’y faire face.

Tout comme une application doit libérer la mémoire qu’elle a allouée une fois que la mémoire n’est plus utilisée, un client d’un objet est chargé de libérer ses références à l’objet lorsque cet objet n’est plus nécessaire. Dans un système orienté objet, le client ne peut le faire qu’en donnant à l’objet une instruction pour se libérer lui-même.

Il est important qu’un objet soit libéré lorsqu’il n’est plus utilisé. La difficulté réside dans la détermination du moment où il convient de libérer un objet. Cela est facile avec les variables automatiques (celles allouées sur la pile) : elles ne peuvent pas être utilisées en dehors du bloc dans lequel elles sont déclarées, de sorte que le compilateur les libère lorsque la fin du bloc est atteinte. Pour les objets COM, qui sont alloués dynamiquement, il appartient aux clients d’un objet de décider quand ils n’ont plus besoin d’utiliser l’objet, en particulier les objets locaux ou distants qui peuvent être utilisés par plusieurs clients en même temps. L’objet doit attendre que tous les clients en soient finis avant de se libérer. Étant donné que les objets COM sont manipulés via des pointeurs d’interface et peuvent être utilisés par des objets dans différents processus ou sur d’autres machines, le système ne peut pas effectuer le suivi des clients d’un objet.

La méthode com pour déterminer quand il est approprié de libérer un objet est le comptage manuel des références. Chaque objet conserve un nombre de références qui suit le nombre de clients qui lui sont connectés, c’est-à-dire le nombre de pointeurs vers l’une de ses interfaces dans n’importe quel client.

Pour plus d'informations, voir les rubriques suivantes :

Utilisation et implémentation d’IUnknown