🚀 go-pugleaf

>> Operacje atomowe na liczniku nie sa wymagane tylko w przypadku, gdy ma 
>> sie pewność, że manipulacja wskaźnikiem odbywa się w jednym wątku 
>> aplikacji.
>
> Ano właśnie nie... :-)
> Są potrzebne tylko wtedy, gdy wątek pierwszy raz spotyka się z danym 
> obiektem.
> Wówczas atomowo podnosi licznik referencji (i od tego momentu ma pewność, 
> że
> nikt mu tego obiektu nie zabije) i może sobie zacząć lokalne zliczanie 
> swoich referencji.

A w jaki sposób wątek sprawdza, czy pierwszy raz spotkał sie z danym 
obiektem, aby ewentualnie atomowo podnieść licznik referencji?

>>>> 3. Zwalnianie większych struktur, może doprowadzić do przepełnienia 
>>>> ramki stosu.
>>>
>>> To się da rozwiązać, choć nie zawsze jest to konieczne. Naiwna
>>> implementacja mark&sweep cierpi na dokładnie ten sam problem.
>>
>> Zawsze można to jakoś rozwiązać. Można się jednak nieźle ździwić, gdy 
>> niby prawidłowy fragment kodu wysypuje nam aplikację.
>
> No tak, tylko Ty to podawałeś jako wadę RC, choć dotyczy to też M&S
> z dokładnie tego samego powodu. I w ten sam sposób się to rozwiązuje.

Nie można stawiać tych dwóch przypadków na jednym poziomie, gdyż shared_ptr 
wymaga rozwiązania problemu na poziomie aplikacji a algorytm "mark & sweep" 
na poziomienie implementacji systemu GC.

>> Trudno uznać za zaletę stuację w której aplikacja zatrzymuje się na dwie 
>> sekundy tylko po to, aby zwolnić zajmowana przez siebie pamięć.
>
> Przesadzasz... poza tym na to też są sposoby... RC jest bardzo często
> wykorzystywany w systemach czasu rzeczywistego, więc chyba nie ma
> lepszego dowodu na istnienie rozwiązania.

RC nie jest jedyna techniką odśmiecania stosowaną w systemach czasu 
rzeczywistygo, co dobitnie świadczy o tym, że jego wady mogą przeszkadzać.

Pozdrawiam.

- Bastek -