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ść".

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

do góry

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. Co gorsza uniemozliwia
dzialanie nowych optymalizacji w kolejnych wersjach JVM - patrz np.
zastosowanie "escape analysis" w nowym HotSpot, co powoduje, ze lokalne dla
funkcji obiekty sa alokowane na stosie.

--
Michal

do góry

On Thu, 30 Jul 2009 03:12:27 -0700 (PDT), Maciej Sobczak
<s...@g...com> 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ść".

Nie, bo ja mam taki zwyczaje ze wielowatkowosc rozwiazuje NAJPIERW.
Nie da sie wielowatkowaoci rozwiazc POTEM; widzialem proby tego i te
proby konczyly sie tragicznie

WealHashMap nie ejs tautomatycznie sycnhronizowana i jak sie chce
uzywac jej w aplikacji wielowatkowej, to tzreba pomyslec odpowiednioe
wczesniej

A.L.

do góry

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"?...

A.L.

do góry

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.

--
Michal

do góry

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. 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". 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"?...

A.L.

do góry

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

do góry

On Thu, 30 Jul 2009 16:14:59 +0200, Michal Kleczek <k...@g...com>
wrote:

>
>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.

O ile pamietam, w WeakHashMap nie moze byc 'wielu szukajacych na raz".
Dostep musi byc scisle ograniczony do jednego klienta

A.L.

do góry

On 30 Lip, 17:21, A.L. <a...@a...com> wrote:

> O ile pamietam, w WeakHashMap nie moze byc 'wielu szukajacych na raz".
> Dostep musi byc scisle ograniczony do jednego klienta

Poproszę o źródło tej informacji (paragrafy, doc, etc.).

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

do góry

On Fri, 31 Jul 2009 02:58:05 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>On 30 Lip, 17:21, A.L. <a...@a...com> wrote:
>
>> O ile pamietam, w WeakHashMap nie moze byc 'wielu szukajacych na raz".
>> Dostep musi byc scisle ograniczony do jednego klienta
>
>Poproszę o źródło tej informacji (paragrafy, doc, etc.).

Wydaje mi sie ze to jest w JavaDoc dla WeakHashMap.

Sprawdzilem. Jest. Pan nie ma dostepu do JavaDoc?...

Oprocz tego, sporo jest dyskusji na Internceie na ten temat, na
przyklad tutaj:

http://cs.oswego.edu/pipermail/concurrency-interest/
2007-September/004412.html

co powoduje ze wole nei ryzykowac i nie stusuje concurrent read w
WeakHashMap

A.L.

P.S. A Pan googla nie ma?

do góry