On Mon, 3 Aug 2009 00:49:21 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>
>Wniosek 1: wiele wątków *może* czytać jedną mapę.
>Wniosek 2: ReadWriteLock jest wystarczającym narzędziem do
>synchronizacji mapy.
>
>Chętnie się dowiem, że nie mam racji - ale poproszę o lepsze
>argumenty.
>Dotychczasowe argumenty są powierzchowne i nie odzwierciedlają
>problemu.
>
>Można oczywiście powołać się na jakąś (nawet oficjalną) istniejącą
>implementację, w której get() jest modyfikatorem. Wtedy oczywiście
>ReadWriteLock nie wystarcza.
>Ale wtedy też będziemy mieli dwie opcje:
>- uznać, że dokumentacja jest do dupy i nie opisuje rzeczywistości
>- uznać, że implementacja jest do dupy i nie działa zgodnie ze
>specyfikacją.
>
>Co byś wybrał?

Ja bym wybral to co przed chwila zrobilem: sciagnalem kod zrodlwoy
WeakHashMap i sprawdzilem naocznie czy mozliwy jest rownolegle
wykonywanie czytania czy nie. Zajelo mi to 5 minut.

Co i Panu polecam

A.L.

do góry

On 4 Sie, 16:45, A.L. <a...@a...com> wrote:

> Ja bym wybral to co przed chwila zrobilem: sciagnalem kod zrodlwoy
> WeakHashMap

Ściągnąłeś kod źródłowy do implementacji, której *JA* używam?

A może ściągnąłeś kod źródłowy do jakiejś *PRZYSZŁEJ WERSJI* tej
implementacji, którą *JA* będę kiedyś używał?

A może ściągnąłeś kod źródłowy do tej implementacji, którą używają
nieznani mi jeszcze użytkownicy biblioteki, którą teraz piszę i w
której chcę użyć WeakHashMap?
Wyobrażasz sobie, że ja sam jeszcze nie wiem, jakiej implementacji
będę używał?

Weź się nie kompromituj. Dla relaksu poczytaj to:

http://en.wikipedia.org/wiki/Encapsulation_(computer
_science)

Pierwszy paragraf, jest tam kilka ważnych słów.

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

do góry

On Tue, 4 Aug 2009 08:26:42 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>On 4 Sie, 16:45, A.L. <a...@a...com> wrote:
>
>> Ja bym wybral to co przed chwila zrobilem: sciagnalem kod zrodlwoy
>> WeakHashMap
>
>Ściągnąłeś kod źródłowy do implementacji, której *JA* używam?

Nie. Ktorej JA uzywam. Dlatego nie podalem wnioskow analizy kodu
ktorego JA uzywam

>
>A może ściągnąłeś kod źródłowy do jakiejś *PRZYSZŁEJ WERSJI* tej
>implementacji, którą *JA* będę kiedyś używał?
>

Poniewaz NIE WIE Pan jakie jwersji bedzie Pan uzaywal i jakie beda
wlasciwosci tej wersji, a standard Javy nic nie mowi na temat
bibliotek, w takim przypadku nalezy przyjac zalozenie minimalne,
mianowicie ze NIA MA deostepu rownloeglego

Albowiem to czy jest dostep roznolegly czy nei nie zalezy w zupelnosci
od panksich pdeudo-logicznych analiz tego czego nei ma w dokumentacji,
a od tego w jaki sposob konkretna biblioteka bedzie zaimplementowana.
A jak mowilem, standard tego nie okresla.


>A może ściągnąłeś kod źródłowy do tej implementacji, którą używają
>nieznani mi jeszcze użytkownicy biblioteki, którą teraz piszę i w
>której chcę użyć WeakHashMap?
>Wyobrażasz sobie, że ja sam jeszcze nie wiem, jakiej implementacji
>będę używał?
>

To niech Pan nei zadaje glupich pytan

>Weź się nie kompromituj. Dla relaksu poczytaj to:
>
>http://en.wikipedia.org/wiki/Encapsulation_(compute
r_science)

Rzeczywiscie, solidne zrodlo"

"This article may contain original research or unverified claims.
Please improve the article by adding references. See the talk page for
details. (May 2009)

This article does not cite any references or sources. Please help
improve this article by adding citations to reliable sources.
Unsourced material may be challenged and removed. (May 2009) "

Ciach Pan pleci je swoim wspolpracownikom.

Wie Pan, jak idzie o nauczanie, to obawiam sie ze ja moglbym uczyc
Pana a nie odwrotnie. Panksie 66 certufikatow i ogolne wymadrzanie nie
robia na mnie zerowe wrazenie

A.L.

do góry

On 4 Sie, 10:52, Piotr Lipski <l...@g...com> wrote:

> Immutable ma się tu jak pięść do nosa. Sens istnienia WeakHashMap jest
> w zmienności -
> usuwane są z niej klucze, które GC zbierze.

Nie napisałem, ze WeakHashMap jest immutable, tylko że bezpieczeństwo
przy wielu wątkach jest związane z brakiem zapisów.

> To czy get jest operacją modyfikującą jest szczegółem implementacji.

To trochę daleko posunięta teza. W dodatku sprzeczna z książką, którą
polecał A.L. i w której pokazano, jak można opakować HashMapę w klasę,
która eksponując tylko get() jest bezpieczna.

> Istotne jest, że w pewnym momencie jakiś obiekt zawarty w WeakHashMap
> jest "weakly reachable". Można więc "go" usunąć z mapy.
> Skąd wiadomo, że jest "weakly reachable"? - zaglądamy do dokumentacji
> WeakReference:

I co - jest tam coś o WeakHashMap.get?

Skąd pomysł, że get() konsumuje kolejkę referencji? Dlaczego nie put
()?
Nie wydaje Ci się, że put() byłby bardziej odpowiednim kandydatem,
skoro i tak jest już logicznie modyfikatorem?

Tak czy inaczej - nawet jeśli get() stymuluje czyszczenie mapy, co z
programem, który nie woła get()?

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

do góry

> > To czy get jest operacją modyfikującą jest szczegółem implementacji.
>
> To nie jest szczegół implementacji, bo od tego zależy, czy wolno robić
> wiele get równolegle.

Jest szczegółem - dokumentacja wyraźnie mówi:

"Because the garbage collector may discard keys at any time, a
WeakHashMap may behave as though an unknown thread is silently
removing entries. In particular, even if you synchronize on a
WeakHashMap instance and invoke none of its mutator methods, it is
possible for the size method to return smaller values over time, for
the isEmpty method to return false and then true, for the containsKey
method to return true and later false for a given key, for the get
method to return a value for a given key but later return null, for
the put method to return null and the remove method to return false
for a key that previously appeared to be in the map, and for
successive examinations of the key set, the value collection, and the
entry set to yield successively smaller numbers of elements."

> > Istotne jest, że w pewnym momencie jakiś obiekt zawarty w WeakHashMap
> > jest "weakly reachable". Można więc "go" usunąć z mapy.
> > Skąd wiadomo, że jest "weakly reachable"? - zaglądamy do dokumentacji
> > WeakReference:
>
> *To* jest właśnie szczegół implementacji. Specyfikacja WeakHashMap nie
> mówi nic o tym, że używa WeakReference.

"Each key object in a WeakHashMap is stored indirectly as the referent
of a weak reference. Therefore a key will automatically be removed
only after the weak references to it, both inside and outside of the
map, have been cleared by the garbage collector."

Jak wół: weak reference.

> Żeby się dowiedzieć, czy wolno robić wiele get równolegle, nie powinno
> być konieczności zastanawiania się, jak WeakHashMap może być
> zaimplementowane. To powinno wynikać ze specyfikacji.

Jest *to* wyraźnie napisane.

> > Dokumentacja jest super. Ty jej nie doczytałeś ;-)
>
> Nie jest.

Dokumentacja jest super. Ty jej nie doczytałeś ;-)

PL

do góry

> > Immutable ma się tu jak pięść do nosa. Sens istnienia WeakHashMap jest
> > w zmienności -
> > usuwane są z niej klucze, które GC zbierze.
>
> Nie napisałem, ze WeakHashMap jest immutable, tylko że bezpieczeństwo
> przy wielu wątkach jest związane z brakiem zapisów.
>
> > To czy get jest operacją modyfikującą jest szczegółem implementacji.
>
> To trochę daleko posunięta teza. W dodatku sprzeczna z książką, którą
> polecał A.L. i w której pokazano, jak można opakować HashMapę w klasę,
> która eksponując tylko get() jest bezpieczna.

Ale co to ma wspólnego z dyskusją na temat WeakHashMap?

> > Istotne jest, że w pewnym momencie jakiś obiekt zawarty w WeakHashMap
> > jest "weakly reachable". Można więc "go" usunąć z mapy.
> > Skąd wiadomo, że jest "weakly reachable"? - zaglądamy do dokumentacji
> > WeakReference:
>
> I co - jest tam coś o WeakHashMap.get?
>
> Skąd pomysł, że get() konsumuje kolejkę referencji? Dlaczego nie put
> ()?
> Nie wydaje Ci się, że put() byłby bardziej odpowiednim kandydatem,
> skoro i tak jest już logicznie modyfikatorem?
> Tak czy inaczej - nawet jeśli get() stymuluje czyszczenie mapy, co z
> programem, który nie woła get()?

wszystko jest w dokumentacji:

"Because the garbage collector may discard keys at any time, a
WeakHashMap may behave as though an unknown thread is silently
removing entries. In particular, even if you synchronize on a
WeakHashMap instance and invoke none of its mutator methods, it is
possible for the size method to return smaller values over time, for
the isEmpty method to return false and then true, for the containsKey
method to return true and later false for a given key, for the get
method to return a value for a given key but later return null, for
the put method to return null and the remove method to return false
for a key that previously appeared to be in the map, and for
successive examinations of the key set, the value collection, and the
entry set to yield successively smaller numbers of elements."

PL

do góry

On Aug 4, 11:01 pm, Piotr Lipski <l...@g...com> wrote:

> "Because the garbage collector may discard keys at any time, a
> WeakHashMap may behave as though an unknown thread is silently
> removing entries.

Czyli z tego by wynikało, że nie wolno wykonywać w ogóle żadnych
operacji na WeakHashMap, bo mogą się przypadkiem zrównoleglić z tym
wątkiem, który usuwa wpisy.

A jeśli wolno, to które operacje wolno wykonywać równolegle ze sobą i
gdzie to jest napisane?

> Dokumentacja jest super. Ty jej nie doczytałeś ;-)

Nie jest.

do góry

On 4 Sie, 23:09, Piotr Lipski <l...@g...com> wrote:

> > > To czy get jest operacją modyfikującą jest szczegółem implementacji.
>
> > To trochę daleko posunięta teza. W dodatku sprzeczna z książką, którą
> > polecał A.L. i w której pokazano, jak można opakować HashMapę w klasę,
> > która eksponując tylko get() jest bezpieczna.
>
> Ale co to ma wspólnego z dyskusją na temat WeakHashMap?

To ma wspólnego, że nie wiadomo, czy dwa wątki użytkownika mogą czytać
obiekt tej klasy.
Wiadomo, że w przypadku HashMap mogą to robić.

Co takiego sprawia, że z WeakHashMap nie mogą? W dokumentacji nic na
ten temat nie ma.

> wszystko jest w dokumentacji:
>
> "Because the garbage collector may discard keys at any time, a
> WeakHashMap may behave as though an unknown thread is silently
> removing entries.
[...]

Czyli nie można wołać get() nawet z jednego wątku?

Otóż można. Dokumentacja mówi, że działalność GC jest widoczna ale
bezpieczna dla mapy i *tylko to* wynika z tego, co zacytowałeś.

Pytanie - czy można wołać get() z dwóch wątków?

Nie wiadomo. Dokumentacja klasy w ogóle nie porusza tego tematu, więc
przypuszczalnie obowiązują ogólne zasady biblioteki (patrz HashMap) i
języka (patrz JLS).

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

do góry

On 4 Sie, 17:37, A.L. <a...@a...com> wrote:

> Poniewaz NIE WIE Pan jakie jwersji bedzie Pan uzaywal i jakie beda
> wlasciwosci tej wersji, a standard Javy nic nie mowi na temat
> bibliotek, w takim przypadku nalezy przyjac zalozenie minimalne,
> mianowicie ze NIA MA deostepu rownloeglego

Acha. Dokumentacja nie zabrania też implementacjom przechowywać całego
stanu mapy w thread local storage.
Czy to znaczy, że w ramach szukania najmniejszego wspólnego mianownika
w ogóle nie wolno używać mapy z wielu wątków, nawet z synchronizacją?

Twoja argumentacja jest bardzo krucha i załamuje się w zasadzie przy
każdej klasie w JDK.

> >Weź się nie kompromituj. Dla relaksu poczytaj to:
>
> >http://en.wikipedia.org/wiki/Encapsulation_(compute
r_science)
>
> Rzeczywiscie, solidne zrodlo"

Nie pajacuj. Wrzuciłem tego linka, bo był najłatwiejszy. Poszukaj
sobie w dowolnym innym źródle co to jest enkapsulacja i po co.
Twoja propozycja czytania kodu implementacji standardowych bibliotek
odbiega nieco od norm inżynierii oprogramowania.

> Wie Pan, jak idzie o nauczanie, to obawiam sie ze ja moglbym uczyc
> Pana

Ależ bardzo chętnie. Właśnie po to zaglądam na grupy, żeby się czegoś
nauczyć. Jestem na to zawsze otwarty.

> Panksie 66 certufikatow i ogolne wymadrzanie

To faktycznie bardzo ciekawy argument w dyskusji o WeakHashMapie. Czy
ja coś wspominałem o certyfikatach? Nie wspominałem.
A może masz jakąś obsesję albo nieuświadomiony kompleks, który się tak
ujawnia?

> nie
> robia na mnie zerowe wrazenie

Polska język trudna język.
Jak na samo-reklamującego się nauczyciela ze stażem akademickim Twoja
nieudolność w składaniu logicznie brzmiących zdań budzi we mnie pewne
zalążki niepokoju.

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

do góry