Delen via

De levensduur van objecten beheren door middel van referentietelling

In traditionele objectsystemen wordt de levenscyclus van objecten, dat wil gezegd, de problemen rondom het maken en verwijderen van objecten impliciet afgehandeld door de taal (of de uitvoeringstijd van de taal) of expliciet door toepassingsprogrammeurs.

In een zich ontwikkelend, decentrally constructed systeem bestaande uit hergebruikte onderdelen, is het niet langer waar dat elke client, of zelfs een programmeur, altijd 'weet' hoe het moet omgaan met de levensduur van een onderdeel. Voor een client met de juiste beveiligingsbevoegdheden is het nog steeds relatief eenvoudig om objecten te maken via een eenvoudige aanvraag, maar het verwijderen van objecten is een andere zaak. Het is niet noodzakelijkerwijs duidelijk wanneer een object niet meer nodig is en moet worden verwijderd. (Lezers die bekend zijn met door garbagecollection verzamelde programmeeromgevingen, zoals Java, kunnen het niet eens zijn. Java-objecten omvatten echter geen machine- of zelfs procesgrenzen, en daarom is de garbagecollection beperkt tot objecten die zich in één procesruimte bevinden. Bovendien dwingt Java het gebruik van één programmeertaal af.) Zelfs wanneer de oorspronkelijke client met het object wordt uitgevoerd, kan het object niet gewoon worden afgesloten, omdat een andere client of clients nog steeds een verwijzing naar het object hebben.

Een manier om ervoor te zorgen dat een object niet meer nodig is, is volledig afhankelijk te zijn van een onderliggend communicatiekanaal om het systeem te informeren wanneer alle verbindingen met een cross-process- of cross-channel-object zijn verdwenen. Regelingen die deze methode gebruiken, zijn echter om verschillende redenen onaanvaardbaar. Een probleem is dat er mogelijk een groot verschil is tussen het programmeermodel voor meerdere processen/netwerken en het programmeermodel met één proces. In het cross-process/cross-network programmeermodel biedt het communicatiesysteem de haken die nodig zijn voor objectlevensbeheer, terwijl in het programmeermodel voor één proces objecten rechtstreeks worden verbonden zonder tussenliggend communicatiekanaal. Een ander probleem is dat dit schema ook kan leiden tot een laag van door het systeem geleverde software die de prestaties van onderdelen in het proces zou verstoren. Bovendien zou een mechanisme op basis van expliciete bewaking niet vaak worden geschaald naar vele duizenden of miljoenen objecten.

COM biedt een schaalbare en gedistribueerde benadering voor deze set problemen. Clients vertellen een object wanneer ze het gebruiken en wanneer ze klaar zijn, en objecten verwijderen zichzelf wanneer ze niet meer nodig zijn. Deze benadering vereist dat alle objecten verwijzingen naar zichzelf tellen. Programmeertalen zoals Java, die inherent hun eigen levensduurbeheerschema's hebben, zoals garbagecollection, kunnen het tellen van COM-verwijzingen gebruiken om COM-objecten intern te implementeren en te gebruiken, zodat de programmeur dit kan voorkomen.

Net zoals een toepassing geheugen moet vrijmaken die het heeft toegewezen zodra dat geheugen niet meer in gebruik is, is een client van een object verantwoordelijk voor het vrijmaken van de verwijzingen naar het object wanneer dat object niet meer nodig is. In een objectgeoriënteerd systeem kan de klant dit alleen doen door het object een instructie te geven om zichzelf vrij te maken.

Het is belangrijk dat de toewijzing van een object ongedaan wordt gemaakt wanneer het niet meer wordt gebruikt. De moeilijkheid ligt bij het bepalen wanneer het gepast is om een object vrij te geven. Dit is eenvoudig met automatische variabelen (die zijn toegewezen aan de stack): ze kunnen niet worden gebruikt buiten het blok waarin ze worden gedeclareerd, zodat de compiler de toewijzing ervan ongedaan maakt wanneer het einde van het blok wordt bereikt. Voor COM-objecten die dynamisch worden toegewezen, is het aan de clients van een object om te bepalen wanneer ze het object niet meer nodig hebben, met name lokale of externe objecten die mogelijk tegelijkertijd door meerdere clients worden gebruikt. Het object moet wachten totdat alle clients ermee klaar zijn voordat het zichzelf vrijmaakt. Omdat COM-objecten worden gemanipuleerd via interfaceaanwijzers en kunnen worden gebruikt door objecten in verschillende processen of op andere computers, kan het systeem de clients van een object niet bijhouden.

COM's methode om te bepalen wanneer het passend is om een object op te heffen, is handmatige referentietelling. Elk object onderhoudt een verwijzingsaantal waarmee wordt bijgehouden hoeveel clients er met het object zijn verbonden. Dat wil gezegd, hoeveel aanwijzers er bestaan op een van de interfaces in elke client.

Zie de volgende onderwerpen voor meer informatie:

IUnknown- gebruiken en implementeren

 

 

  • Last updated on