A.L. wrote:

> On Thu, 30 Jul 2009 14:49:00 +0200, Michal Kleczek <k...@g...com>
> wrote:
>
>>A.L. wrote:
>>
>>> On Thu, 30 Jul 2009 13:15:24 +0200, Michal Kleczek <k...@g...com>
>>> wrote:
>>>
>>>>Maciej Sobczak wrote:
>>>>
>>>>> On 29 Lip, 15:14, A.L. <a...@a...com> wrote:
>>>>>
>>>>>> Do kreowania "dummy" ja bym bie robil konstruktora ale statyczna
>>>>>> metode createKey. Na dodatek, wystarczy jeden egzemplarz "dummy"
>>>>>> jeseli zrobimy druga methode umozliwiajaca zmiane ID
>>>>>
>>>>> A na drugi dzień będziesz rozwiązywał nowy problem o nazwie
>>>>> "wielowątkowość".
>>>>>
>>>>
>>>>Wtedy trzymasz oddzielne "dummy" dla kazdego watku w ThreadLocal :)
>>>>
>>>>A tak powazniej - IMHO w wiekszosci wypadkow w Javie proba "polepszenia"
>>>>programu poprzez _unikanie_ GC zle sie konczy.
>>>
>>> Czy Kolega moglby pokazac gezie w tym watku jest proba "unikania
>>> GC"?...
>>
>>Trzymanie jednego "dummy", ktory jest mutable - rozumiem, ze to
>>taka "optymalizacja" po to, zeby nie tworzyc nowego obiektu za kazdym
>>razem, gdy chcemy cos w mapie znalezc.
>
> Po pierwsze, nie "optymalizacja" a optymalizacja - kreowanie Item moze
> byc kosztowne i nei ma co go tworzyc za kazdym razem gdy potrzebujemy
> klucz.

Z tym ze przy tym rozwiazaniu znacznie lepiej byloby zrobic specjalny
prywatny konstruktor pozwalajacy tworzyc "dummy" item bez ponoszenia tych
kosztow (oprocz alokacji pamieci na Item - jezeli tylko tego chcemy uniknac
to jest to wlasnie "unikanie GC").

> Slusznie zauwazyl pan Sobczak ze nalezy unikac raczej
> rownoleglego dostepu do "dummy", ale rozniez nalezy unikac
> rownoleglego dostepu do WeakHashMap. Z tego powodu dostep do dummy,
> ustawienie ID oraz wyszukiwanei nalezy umiescic w jednej metodzie i
> zrobic tak zeby byla "atomowa".

Tyle, ze rozwiazanie z jednym "dummy" powoduje, ze do atomowosci operacji
wyszukiwania nie mozna uzyc np. ReadWriteLock, bo kazda operacja szukania
wiaze sie ze zmiana stanu wspoldzielonego obiektu - czyli moze byc
obsluzony tylko jeden szukajacy naraz.

> Obiekt "dummy" w ogole nie musi byc
> manipulowany pzrez klienta, ani w ogole klient nie musi wiedziec o
> jego istnieniu
>
> Po drugie - co to ma wspolnego z "unikaniem GC"?...
>

Patrz wyzej.

--
Michal