Michal Kleczek wrote:
> Krzysiek Kowaliczek wrote:
>> Wcale nie musisz używać "sprytnych wskaźników", np.:
>> zapamiętujesz obiekty Item w liście, wyświetlasz okna
>> lub inaczej "cudujesz" z obiektami Item. Po przetwarzaniu
>> usuwasz obiekty z listy.
>>
>
> A skad wiesz _kiedy_ mozna juz usunac Item z listy?
>

Ponieważ tak zaprojektowałem sobie system, że znam
czasy życia na poszczególnych etapach przetwarzania.
Serio, często tak robie zamiast spontanicznego i
radosnego używania sprytnych wskaźników gdzie popadnie.

Pozdrawiam
KK

do góry

Maciej Sobczak wrote:

> On 27 Lip, 12:09, Michal Kleczek <k...@g...com> wrote:
>
>> > Nie trzeba watku skanujacego - wystarczy usuwajacy. Od skanowania jest
>> > java.lang.ref.ReferenceQueue
>>
>> Sprobuj moze jakos tak:
>
> [...]
>
> Tak, to wygląda ciekawie. W moim przypadku mogłoby to być nawet trochę
> prostsze, ale rdzeń rozwiązania pasuje do problemu. Dziękuję za
> pomysł.

Tak sobie jeszcze to przejrzalem i jest tam pare problemow zwiazanych z
faktem, ze jezeli obiekt Reference nie jest osiagalny to nie zostanie
umieszczony w ReferenceQueue. To powoduje taka sytuacje, ze w wypadku gdy
mapa jest pusta i przestanie byc osiagalna - watek czyszczacy nigdy sie nie
obudzi z referenceQueue.remove().

--
Michal

do góry

On 27 Lip, 13:22, Michal Kleczek <k...@g...com> wrote:

> Na poczatku wlasnie pytalem o kawalek kodu w cpp, ktory robi to _bez_ uzycia
> smart pointerow - ktore defacto sa namiastka GC.

To, czy użytkownik użyje smart pointery nie ma tu znaczenia, bo to
użycie byłoby na innym poziomie kodu. Najbardziej typowy scenariusz to
Item istniejący lokalnie - jego destruktor sprząta odpowiedni wpis w
mapie. Inne scenariusze są nadal możliwe, ale mechanizm czyszczenia
mapy jest ten sam, czyli nadal oparty na destruktorze klasy Item.

Problemem jest właśnie powiązanie obiektów Item z mapą.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

do góry

On 27 Lip, 11:50, Krzysiek Kowaliczek
<k...@g...com> wrote:

> > Oczywiście zmiany okresu skanowania mapy wpływają jedynie na
> > *prawdopodobieństwo* poprawnego działania całego programu i nigdy nie
> > można tej poprawności *zagwarantować*.
>
> Dlaczego? Watek sprzątający może sam "kopnąć" GC.

Ale problem polega na tym, że wątek sprzątający zwykle śpi w czasie,
gdy *być może* brakuje pamięci. Cykl pracy wątku sprzątającego
kompletnie nie zależy od tego, kiedy brakuje pamięci.

> > Jedną z możliwości jest dodatnie do klasy Item funkcji close() i
> > uprzejme poproszenie programisty, żeby jej używał. Jest to
> > rozwiązanie, którego poziom abstrakcji i wartość projektowa
> > odpowiadają językowi C.
>
> To nie jest złe. Dla bezpieczeństwa w finalizatorze można
> dodać asercje o niezwolnionym obiekcie.

Mam robić wiochę jako uzupełnienie kiepskiego rozwiązania? :-D

> > Są inne?
>
> Może zobaczyć jak zaimplementowali WeakHashMap ( tam "weak"
> jest klucz a nie wartość ).

Jest to jakaś opcja, ale chyba Sebastian podrzucił coś znacznie
prostszego.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

do góry

Krzysiek Kowaliczek wrote:

> Michal Kleczek wrote:
>> Krzysiek Kowaliczek wrote:
>>> Wcale nie musisz używać "sprytnych wskaźników", np.:
>>> zapamiętujesz obiekty Item w liście, wyświetlasz okna
>>> lub inaczej "cudujesz" z obiektami Item. Po przetwarzaniu
>>> usuwasz obiekty z listy.
>>>
>>
>> A skad wiesz _kiedy_ mozna juz usunac Item z listy?
>>
>
> Ponieważ tak zaprojektowałem sobie system, że znam
> czasy życia na poszczególnych etapach przetwarzania.
> Serio, często tak robie zamiast spontanicznego i
> radosnego używania sprytnych wskaźników gdzie popadnie.
>

OK

Ale to jest trudne w wypadku przetwarzania wielowatkowego - mamy dwa watki
obslugi zdarzen dwoch okienek pokazujacych ten sam Item oraz watek
przetwarzajacy komunikaty dajmy na to z gniazda i uaktualniajacy
odpowiednie Itemy.

--
Michal

do góry

On 27 Lip, 12:24, "Sebastian Nibisz" <e...@p...onet.pl> wrote:
> Ja zaproponuje takie rozwiązanie.
>
> 1. Oprócz mapy kluczy, utworzyć kolejkę par [ID, Item].
> 2. W konstruktorze obiektu Item
>     a) pobrać N > 1 par z kolejki,
>     b) usunąć z mapy wpisy z martwymi referencjami,
>     c) pary z żywymi referencjami dodać na koniec kolejki,
>     d) utworzyć parę [ID, Item] dla bieżącego obiektu i dodać ja do mapy,
> oraz na koniec kolejki.

Tak naprawdę to całe rozwiązanie jest w 2b (brute-force to po prostu
pełny skan mapy w każdym konstruktorze Item). Nie potrzeba już żadnych
kolejek.
Nadal jest potencjalny problem z pamięcią, bo całość zależy od tego,
czy program będzie w przyszłości wołał konstruktory Item - czyli
zwalnianie pamięci jest stymulowane przez tworzenie obiektów jednego
tylko typu. Być może program nie stworzy już żadnego takiego obiektu.

Niemniej, to rozwiązanie jest dobre w połączeniu z obecnym cyklicznym
wątkiem.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

do góry

On 27 Lip, 13:40, Michal Kleczek <k...@g...com> wrote:

> Tak sobie jeszcze to przejrzalem i jest tam pare problemow zwiazanych z
> faktem, ze jezeli obiekt Reference nie jest osiagalny to nie zostanie
> umieszczony w ReferenceQueue. To powoduje taka sytuacje, ze w wypadku gdy
> mapa jest pusta i przestanie byc osiagalna - watek czyszczacy nigdy sie nie
> obudzi z referenceQueue.remove().

To nie jest problemem w moim przypadku, bo ta mapa istnieje zawsze - a
tak naprawdę jej istnienie jest powiązane z paroma zewnętrznymi
zasobami (to jest system rozproszony), więc musi być spełnione jedno z
dwóch:
* wszystkie ważne obiekty i wątki istnieją w nieskończoność
* gdzieś jest jakaś "rodzicielska" funkcja close(), która wszystko
zwija, łącznie z mapą i wątkami

Tzn. ta mapa nigdy nie przestaje być osiągalna ot tak jak jakiś za
przeproszeniem Item. :-)

To co można uprościć to wywalenie mapowania w drugą stronę - jak już
pisałem, Item zna swój id, więc druga osobna mapa nie jest potrzebna.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

do góry

Maciej Sobczak wrote:

> On 27 Lip, 13:22, Michal Kleczek <k...@g...com> wrote:
>
>> Na poczatku wlasnie pytalem o kawalek kodu w cpp, ktory robi to _bez_
>> uzycia smart pointerow - ktore defacto sa namiastka GC.
>
> To, czy użytkownik użyje smart pointery nie ma tu znaczenia, bo to
> użycie byłoby na innym poziomie kodu. Najbardziej typowy scenariusz to
> Item istniejący lokalnie - jego destruktor sprząta odpowiedni wpis w
> mapie. Inne scenariusze są nadal możliwe, ale mechanizm czyszczenia
> mapy jest ten sam, czyli nadal oparty na destruktorze klasy Item.
>

A jaka to roznica (oprocz tego _kiedy_ wpis zostanie usuniety z mapy) czy to
bedzie destruktor czy finalizer? Przy GC i tak nie ma determinizmu...

--
Michal

do góry

Maciej Sobczak wrote:
> On 27 Lip, 11:50, Krzysiek Kowaliczek
> <k...@g...com> wrote:
>
>>> Oczywiście zmiany okresu skanowania mapy wpływają jedynie na
>>> *prawdopodobieństwo* poprawnego działania całego programu i nigdy nie
>>> można tej poprawności *zagwarantować*.
>> Dlaczego? Watek sprzątający może sam "kopnąć" GC.
>
> Ale problem polega na tym, że wątek sprzątający zwykle śpi w czasie,
> gdy *być może* brakuje pamięci. Cykl pracy wątku sprzątającego
> kompletnie nie zależy od tego, kiedy brakuje pamięci.
>

Można go obudzić w czasie tworzenia Item. Ewentualnie
zrezygnować z dodatkowego wątku i przeprowadzać czyszczenie
w czasie tworzenia Item.

>>> Jedną z możliwości jest dodatnie do klasy Item funkcji close() i
>>> uprzejme poproszenie programisty, żeby jej używał. Jest to
>>> rozwiązanie, którego poziom abstrakcji i wartość projektowa
>>> odpowiadają językowi C.
>> To nie jest złe. Dla bezpieczeństwa w finalizatorze można
>> dodać asercje o niezwolnionym obiekcie.
>
> Mam robić wiochę jako uzupełnienie kiepskiego rozwiązania? :-D
>

Oczywiście. Najlepiej "cichaczem" ukryć przed programistą
problem niezwolnionych zasobów. Później dopiero jest wiocha
na sto dwa jak zaczyna brakować deskryptorów plików u
klienta. Jak dla mnie sytuacja jest prosta nie zwolniłeś
zasobu to asercją po łapach.

Pozdrawiam
KK

do góry

On Mon, 27 Jul 2009 01:38:18 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>Jest
>
>Jedną z możliwości jest dodatnie do klasy Item funkcji close() i
>uprzejme poproszenie programisty, żeby jej używał. Jest to
>rozwiązanie, którego poziom abstrakcji i wartość projektowa
>odpowiadają językowi C.
>Są inne?

WeakHashMap?...

A hashtable-based Map implementation with weak keys. An entry in a
WeakHashMap will automatically be removed when its key is no longer in
ordinary use. More precisely, the presence of a mapping for a given
key will not prevent the key from being discarded by the garbage
collector, that is, made finalizable, finalized, and then reclaimed.
When a key has been discarded its entry is effectively removed from
the map, so this class behaves somewhat differently than other Map
implementations.

A.L.

do góry