Reguli pentru gestionarea numarului de referinte – aplicatii Win32

• 31.05.2018
• 4 minute de citit

In acest articol

Utilizarea unui numar de referinte pentru a gestiona durata de viata a unui obiect permite mai multor clienti sa obtina si sa elibereze accesul la un singur obiect fara a fi nevoie sa se coordoneze intre ei in gestionarea duratei de viata a obiectului. Atata timp cat obiectul client se conformeaza anumitor reguli de utilizare, obiectul, de fapt, asigura aceasta gestionare. Aceste reguli specifica modul de gestionare a referintelor intre obiecte. (COM nu specifica implementarile interne ale obiectelor, desi aceste reguli sunt un punct de plecare rezonabil pentru o politica din cadrul unui obiect.)

Conceptual, indicatorii de interfata pot fi considerati ca rezidand in variabilele de pointer care includ toata starea de calcul intern care detine un pointer de interfata. Aceasta ar include variabile in locatiile de memorie, in registrele interne ale procesorului si atat variabilele generate de programator, cat si cele generate de compilator. Atribuirea sau initializarea unei variabile pointer implica crearea unei noi copii a unui pointer deja existent. In cazul in care a existat o copie a indicatorului intr-o variabila (valoarea utilizata in atribuire / initializare), acum exista doua. O alocare unei variabile pointer distruge copia pointer in prezent in variabila, la fel si distrugerea variabilei in sine. (Adica, sfera in care se gaseste variabila, cum ar fi cadrul stivei, este distrusa.)

Din perspectiva clientului COM, contorizarea referintelor se face intotdeauna pentru fiecare interfata. Clientii nu ar trebui sa presupuna niciodata ca un obiect foloseste acelasi contor pentru toate interfetele.

Cazul implicit este ca AddRef trebuie apelat pentru fiecare copie noua a unui indicator de interfata si Release trebuie apelat pentru fiecare distrugere a unui indicator de interfata, cu exceptia cazului in care urmatoarele reguli permit altfel:

• Parametrii de intrare-iesire a functiilor. Apelantul trebuie sa apeleze AddRef pe parametru, deoarece va fi lansat (cu un apel catre Release ) in codul de implementare atunci cand valoarea de iesire este stocata deasupra acestuia.
• Preluarea unei variabile globale. Cand creati o copie locala a unui indicator de interfata dintr-o copie existenta a indicatorului intr-o variabila globala, trebuie sa apelati AddRef pe copia locala, deoarece o alta functie ar putea distruge copia din variabila globala in timp ce copia locala este inca valabila.
• Noi indicii sintetizati din „aer subtire”. O functie care sintetizeaza un pointer de interfata folosind cunostinte interne speciale, mai degraba decat sa o obtina de la o alta sursa, trebuie sa apeleze initial AddRef pe pointerul nou sintetizat. Exemple importante de astfel de rutine includ rutine de creare a instantelor, implementari ale QueryInterface etc.
• Preluarea unei copii a unui pointer stocat intern. Cand o functie preia o copie a unui pointer care este stocat intern de obiectul apelat, codul obiectului respectiv trebuie sa apeleze AddRef pe pointer inainte ca functia sa revina. Odata ce pointerul a fost recuperat, obiectul de origine nu are alta modalitate de a determina modul in care durata sa de viata se refera la cea a copiei stocate intern a pointerului.

Singurele exceptii de la cazul implicit necesita ca codul de gestionare sa cunoasca relatiile duratei de viata a doua sau mai multe copii ale unui pointer la aceeasi interfata pe un obiect si sa se asigure pur si simplu ca obiectul nu este distrus permitand numarului sau de referinte sa zero. In general, exista doua cazuri, dupa cum urmeaza:

• Cand exista deja o copie a unui pointer si apoi se creeaza o a doua si apoi este distrusa in timp ce prima copie exista inca, apelurile catre AddRef si Release pentru a doua copie pot fi omise.
• Atunci cand exista o copie a unui pointer si se creeaza un al doilea si apoi primul este distrus inainte de al doilea, apelurile catre AddRef pentru a doua copie si la Release pentru prima copie pot fi omise.

Urmatoarele sunt exemple specifice ale acestor situatii, primele doua fiind deosebit de frecvente:

• In parametrii functiilor. Durata de viata a copiei unui indicator de interfata trecut ca parametru la o functie este imbricata in cea a indicatorului utilizat pentru a initializa valoarea, deci nu este nevoie de un numar de referinte separat pentru parametru.
• Iesiti parametrii din functii, inclusiv valorile returnate. Pentru a seta parametrul, functia trebuie sa aiba o copie stabila a indicatorului de interfata. La intoarcere, apelantul este responsabil pentru eliberarea indicatorului. Prin urmare, parametrul out nu are nevoie de un numar de referinte separat.
• Variabile locale. O implementare a metodei controleaza durata de viata a fiecareia dintre variabilele pointer alocate pe cadrul stivei si poate utiliza acest lucru pentru a determina cum sa omiteti perechile AddRef / Release redundante .
• Backpointers. Unele structuri de date contin doua obiecte, fiecare cu un pointer catre celalalt. Daca se stie ca durata de viata a primului obiect contine durata de viata a celui de-al doilea, nu este necesar sa aveti un numar de referinte pe indicatorul celui de-al doilea obiect catre primul obiect. Adesea, evitarea acestui ciclu este importanta in mentinerea comportamentului adecvat de alocare. Cu toate acestea, indicatoarele nenumarate ar trebui utilizate cu precautie extrema, deoarece portiunea sistemului de operare care gestioneaza procesarea la distanta nu are cum sa stie despre aceasta relatie. Prin urmare, in aproape toate cazurile, ca backpointerul sa vada un al doilea obiect „prieten” al primului pointer (evitand astfel circularitatea) este solutia preferata. Arhitectura obiectelor conectabile COM, de exemplu, utilizeaza aceasta abordare.

Atunci cand implementati sau utilizati obiecte cu referinta, poate fi util sa aplicati numere de referinta artificiale , care garanteaza stabilitatea obiectelor in timpul procesarii unei functii. In implementarea unei metode a unei interfete, puteti apela functii care au sansa de a diminua numarul de referinte la un obiect, provocand o eliberare prematura a obiectului si esecul implementarii. O modalitate robusta de a evita acest lucru este sa inserati un apel catre AddRef la inceputul implementarii metodei si sa-l asociati cu un apel la Release imediat inainte ca metoda sa revina.

In unele situatii, valorile returnate ale AddRef si Release pot fi instabile si nu ar trebui sa se bazeze pe ele; acestea trebuie utilizate numai in scopuri de depanare sau diagnostic.

Gestionarea duratei de viata a obiectelor prin numararea referintelor