Interfejsy mają licznik referencji, IUnknown ma metody _AddRef i _Release,
gdy licznik osiągnie zero, są zwalniane. A co się dzieje gdy jest Garbage
Collector i zwalniane są w inny sposób? Poza tym obiekt którego klasa
dziedziczy z interefejsu może mieć pola wskazujące na inne obiekty i
zwalnianie z licznika referencji może być nieskuteczne.

do góry

Borneq <b...@a...hidden.pl> napisał(a):

> Interfejsy mają licznik referencji, IUnknown ma metody _AddRef i _Release,
> gdy licznik osiągnie zero, są zwalniane.
Ok.

> A co się dzieje gdy jest Garbage Collector i zwalniane są w
> inny sposób?
Nie rozumiem czego się obawiasz. Gdy jest zero to są
zwalniane, a sposób w jaki są zwalnianie nie ma znaczenia.

> Poza tym obiekt którego klasa dziedziczy z interefejsu może mieć
> pola wskazujące na inne obiekty i zwalnianie z licznika referencji
> może być nieskuteczne.
Aby było skuteczne, Release i dekrementacja licznika musi zachodzić
rekurencyjnie. W tym przypadku Release musi być wywołana dla każdego
pola wskazującego na inne obiekty.

Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Użytkownik "M.M. " <m...@N...gazeta.pl> napisał w wiadomości
news:jpk0rc$922$1@inews.gazeta.pl...
>> A co się dzieje gdy jest Garbage Collector i zwalniane są w
>> inny sposób?
> Nie rozumiem czego się obawiasz. Gdy jest zero to są
> zwalniane, a sposób w jaki są zwalnianie nie ma znaczenia.

Czy w językach z GC można zwalniać przez delete? Czy też raczej nie stosuje
się tego, bo po delete zostaną wiszące referencje, a zwolnienie obiektu z
interfejsem przez licznik tego nie powoduje. Jednak co gdy mamy GC
przenoszący dane do ciąglego obszaru przy zwalnianiu aby maksymalnie
przyśpieszyc alokację? Czy tylko takie zwalnianie bez GC to zmiana flagi na
"zwolnione" ale bez odzyskania pamieci?

> Aby było skuteczne, Release i dekrementacja licznika musi zachodzić
> rekurencyjnie. W tym przypadku Release musi być wywołana dla każdego
> pola wskazującego na inne obiekty.

A co gdy powstają cykle? Klasa C dziedzicząca interfejs ma pole klasy C. A
obiekt p0 wskazuje na p1 a p1 na p0.

Pozdrawiam

Chciałem się jeszcze dopytać o kolektory przenoszące Mark & compact. Wtedy
alokacja jest łyskawiczna, jedynie przesunięcie wskaźnika i można sobie
darować obiektu bez alokacji na stosie. Ale co ze zwalnianiem, takie
kopiowanie moze znacznie spowolnić. I jak to jest robione, dla dużych
obiektów opłacało by się mieć tablicę wskaźników pośrednich, która była by
zmieniana (pozostają problemy gdy taka tablica rośnie, Realloc - tu już nie
można jedynie przesuwać wskaźnika) A co z mniejszymi? Wypadałoby że tak
samo, bo jak inaczej? Trzeba by modyfikowac wszystkie pola gdzie sa
wskaźniki wstecznie a wskaźnik jest jednokierunkowy.

do góry

Użytkownik "Borneq" <b...@a...hidden.pl> napisał w wiadomości
news:jpkdd1$ogc$1@inews.gazeta.pl...
> interfejsem przez licznik tego nie powoduje. Jednak co gdy mamy GC
> przenoszący dane do ciąglego obszaru przy zwalnianiu aby maksymalnie
> przyśpieszyc alokację? Czy tylko takie zwalnianie bez GC to zmiana flagi
> na "zwolnione" ale bez odzyskania pamieci?

Obiekt z AddRef,Release raczej nie powinien byc zwalniany przy odśmiecaniu,
ale to rodzi problemy - nie ma ciągłego miejsca po odśmieceniu i zostaje
niezwolniony gdy są cykle.

do góry

On May 24, 5:28 am, "Borneq" <b...@a...hidden.pl> wrote:
> Użytkownik "M.M. " <m...@N...gazeta.pl> napisał w
wiadomościnews:jpk0rc$922$1@inews.gazeta.pl...
>
> >> A co się dzieje gdy jest Garbage Collector i zwalniane są w
> >> inny sposób?
> > Nie rozumiem czego się obawiasz. Gdy jest zero to są
> > zwalniane, a sposób w jaki są zwalnianie nie ma znaczenia.
>
> Czy w językach z GC można zwalniać przez delete? Czy też raczej nie stosuje
> się tego, bo po delete zostaną wiszące referencje, a zwolnienie obiektu z
> interfejsem przez licznik tego nie powoduje.

Interfejsy COM, o które, jak rozumiem, ci chodzi, nie są związane z
żadnym językiem. One są protokołem do komunikacji między komponentami
(oddzielnymi programami lub programem i biblioteką DLL) i nie powinny
w żadnym wypadku być stosowane do komunikacji wewnątrz danego
komponentu.

Założenia podziału na komponenty są takie, że każdy komponent może być
zaimplementowany w innym języku, i każdy sam zarządza swoją pamięcią.
Liczniki referencji służa tylko do określenia, czy dany obiekt jest
używany jeszcze poza danym komponentem, czy możesz go usunąć.

> Jednak co gdy mamy GC
> przenoszący dane do ciąglego obszaru przy zwalnianiu aby  maksymalnie
> przyśpieszyc alokację? Czy tylko takie zwalnianie bez GC to zmiana flagi na
> "zwolnione" ale bez odzyskania pamieci?

Interfejsy COM jako takie nie mogą być relokowane, bo są
identyfikowane przez wskaźnik. Ale w związku z tym tak czy inaczej
serwer COM musi być implementowany w języku dającym dostęp do takich
niskopoziomowych konceptów. Normalnie jak sądzę jest tak, że tworząc
serwer COM w języku wysokopoziomowym będziesz korzystał ze wsparcia
zaimplementowanego w języku odpowiednio niskopoziomowym,
prawdopodobnie w C++ - i albo takie wsparcie masz wbudowane, albo
będziesz je sam musiał sobie dopisać. Polegałoby to w skrócie na tym,
że masz jakąś ręcznie zarządzaną stertę czy inną kolekcję z obiektami
proxy, które z jednej strony mają stały adres i zawierają wskaźnik na
tablicę funkcji wirtualnych implementujących dany interfejs COM, a z
drugiej strony zawierają 'sprytną referencję' do obiektu w docelowym
języku, rejestrowaną w runtime tak, żeby garbage collector ją widział
- w tej sposób każdy obiekt, dla którego istnieje interfejs COM jest
'live' niezależnie od tego, czy są na niego jakieś inne referencje. W
momencie, kiedy licznik referencji na obiekcie proxy osiągnie 0, jest
on usuwany z kolekcji interfejsów i referencja na niego zostaje
usunięta. O ile nie ma żadnych innych referencji, referowany obiekt
zostanie usunięty w następnym cyklu odśmiecania.

> > Aby było skuteczne, Release i dekrementacja licznika musi zachodzić
> > rekurencyjnie. W tym przypadku Release musi być wywołana dla każdego
> > pola wskazującego na inne obiekty.
>
> A co gdy powstają cykle? Klasa C dziedzicząca interfejs ma pole klasy C. A
> obiekt p0 wskazuje na p1 a p1 na p0.

Liczenie referencji jako ogólna metoda jest podatna na cykle. W
przypadku COM problem nie jest tak bardzo poważny o tyle, że
komponenty komunikują się w architekturzy klient-serwer, gdzie serwer
tylko wystawia interfejsy a klient tylko z nich korzysta. Teoretycznie
możliwe jest powstanie cykli, jeśli występują cykle na poziomie
komponentów (komponent A jest klientem komponentu B, B jest klientem
komponentu C, C jest klientem A), ale to już jest problem na poziomie
architektury systemu: generalnie takich projektów powinno się unikać,
a w ekstremalnych sytuacjach, kiedy się już absolutnie nie da tego
uniknąć, trzeba zadbać, żeby nie występowały cykliczne zależności
blokujące zwolnienie zasobów.

> Chciałem się jeszcze dopytać o kolektory przenoszące Mark & compact. Wtedy
> alokacja jest łyskawiczna, jedynie przesunięcie wskaźnika i można sobie
> darować obiektu bez alokacji na stosie. Ale co ze zwalnianiem, takie
> kopiowanie moze znacznie spowolnić.

Może, i długie cykle odśmiecania są realnym problemem. Ale po pierwsze
rozwiązuje się to w ten sposób, że skopiowanie obiektu można wykonać
przez zwykłe skopiowanie obszaru pamięci, a po drugie założenie
wydajnościowe kolektorów kompaktujących/przenoszących jest takie, że w
momencie odśmiecania większość obiektów na danej stercie to śmieci - a
kosztuje tylko przeniesienie żywych obiektów.

> I jak to jest robione, dla dużych
> obiektów opłacało by się mieć tablicę wskaźników pośrednich, która była by
> zmieniana (pozostają problemy gdy taka tablica rośnie, Realloc - tu już nie
> można jedynie przesuwać wskaźnika) A co z mniejszymi? Wypadałoby że tak
> samo, bo jak inaczej? Trzeba by modyfikowac wszystkie pola gdzie sa
> wskaźniki wstecznie a wskaźnik jest jednokierunkowy.

Można tworzyć dodatkowe tymczasowe struktury/pola, istniejące tylkow
cyklu odśmiecania, które pamiętają co i gdzie było przenoszone. W
praktyce można to zrobić przez odpowiednią konstrukcję sterty.
Dodatkowo pomocne jest rozwiązanie, gdzie przenoszenie następuje tylko
między rozłącznymi obszarami: ze sterty A przenosisz do sterty B, więc
patrząc na wskaźnik od razu możesz stwierdzić, na którą stertę
wskazuje. Jeśli wskazuje na 'nową' to nic dalej nie trzeba robić.
Jeśli wskazuje na 'starą', to używając owych struktur można sprawdzić,
czy obiekt już został przeniesiony ze starej na nową i ewentualnie
jaki jest jego adres na nowej stercie.

W praktyce współczesne systemy z odśmiecaniem, w których istotna jest
wysoka wydajność, stosują odśmiecanie pokoleniowe z różnymi
strategiami dla kolejnych pokoleń.

do góry

Andrzej Jarzabek <a...@g...com> napisał(a):

> Liczenie referencji jako og=F3lna metoda jest podatna na cykle.
W jaki sposób używasz słowa 'podatna'?

Ja bym napisał że jest odporna na cykle. Jeśli ilość_referencji równa
się zero to nie wykonujemy rekurencyjnego zwalniania.

Pozdrawiam



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On May 25, 3:08 pm, " M.M." <m...@N...gazeta.pl> wrote:
> Andrzej Jarzabek <a...@g...com> napisał(a):
>
> > Liczenie referencji jako og=F3lna metoda jest podatna na cykle.
>
> W jaki sposób używasz słowa 'podatna'?
>
> Ja bym napisał że jest odporna na cykle. Jeśli ilość_referencji równa
> się zero to nie wykonujemy rekurencyjnego zwalniania.

Używam w sensie "nie działa prawidłowo jeśli są cykle". Wydaje mi się,
że "podatna na cykle" jest bardziej odpowiednim określeniem takiego
stanu rzeczy niż "odporna na cykle" (co dla mnie sugerowałoby coś
zupełnie przeciwnego), ale nie będę się o to kłócił.

do góry

On 25 Maj, 16:40, Andrzej Jarzabek <a...@g...com> wrote:

> Używam w sensie "nie działa prawidłowo jeśli są cykle". Wydaje mi się,
> że "podatna na cykle" jest bardziej odpowiednim określeniem takiego
> stanu rzeczy niż "odporna na cykle" (co dla mnie sugerowałoby coś
> zupełnie przeciwnego), ale nie będę się o to kłócił.

Proponuję na zgodę słowo "wrażliwa na cykle".

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On 26/05/2012 08:02, Maciej Sobczak wrote:
> On 25 Maj, 16:40, Andrzej Jarzabek<a...@g...com> wrote:
>
>> Używam w sensie "nie działa prawidłowo jeśli są cykle". Wydaje mi się,
>> że "podatna na cykle" jest bardziej odpowiednim określeniem takiego
>> stanu rzeczy niż "odporna na cykle" (co dla mnie sugerowałoby coś
>> zupełnie przeciwnego), ale nie będę się o to kłócił.
>
> Proponuję na zgodę słowo "wrażliwa na cykle".

Dla mnie bomba.

do góry

W dniu 24.05.2012 r. 0:49, Borneq pisze:
> Interfejsy maj? licznik referencji, IUnknown ma metody _AddRef i _Release,
> gdy licznik osi?gnie zero, s? zwalniane. A co sie dzieje gdy jest Garbage
> Collector i zwalniane s? w inny sposób? Poza tym obiekt którego klasa
> dziedziczy z interefejsu mo?e mieae pola wskazuj?ce na inne obiekty i
> zwalnianie z licznika referencji mo?e byae nieskuteczne.
Masz popsute kodowanie.

do góry