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

Tak na marginesie: jedyne co mozna powiedziec na pewno to to ze
kontenery oferujace pelna rowoleglosc to sa te ktore umieszczone sa w
pakiecie util.concurrent

Inne sa delkarowane explicite jako nie synchronizowane, a
"sunchronizing wrapper" umozliwia uczynienie ich "thread safe" ale nie
"concurrent".

Poelcam ksiazki:

Brian Goetz + 10 innych: "Java Concurrency in Practice" (dokladne
omowienie util.concurrent, no moze nie takei dokladne ale moze byc :)

Maurice Naftalin, Philip Wadler "Java Generics and Collections" gdzie
tez jest troche dyskusji nad concurrency

A.L.

do góry

On 31 Lip, 14:08, A.L. <a...@a...com> wrote:

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

Mam, ale nie potrafię znaleźć odpowiedniego fragmentu.

Poproszę o pomoc. Albo cytat.

> Oprocz tego, sporo jest dyskusji na Internceie na ten temat, na
> przyklad tutaj:
>
> http://cs.oswego.edu/pipermail/concurrency-interest/
2007-September/00...

Nie, to nie jest na ten temat. Ktoś opowiada, że przeczytał jakiś kod.
A mnie interesuje, co jest w specyfikacji. Albo w dokumentacji.

Poproszę o cytat z dokumentacji wskazujący na niemożliwość czytania
WeakHashMapy z wielu wątków.

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

do góry

> > >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?...
>
> Mam, ale nie potrafię znaleźć odpowiedniego fragmentu.
>
> Poproszę o pomoc. Albo cytat.

Jak wół stoi:

"Like most collection classes, this class is not synchronized. A
synchronized WeakHashMap may be constructed using the
Collections.synchronizedMap method."

http://java.sun.com/javase/6/docs/api/index.html

PL

do góry

On Sat, 1 Aug 2009 14:31:33 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>O
>
>Poproszę o cytat z dokumentacji wskazujący na niemożliwość czytania
>WeakHashMapy z wielu wątków.

Cytat: "Like most collection classes, this class is not synchronized.
A synchronized WeakHashMap may be constructed using the
Collections.synchronizedMap method."

To znaczy ze to nie jest "thread safe". Jak nie jes tthread safe, to
na pewno nie jest concurrent.

Jek sie uzyje synchronizedMap, to cytuje

"Returns a synchronized (thread-safe) collection backed by the
specified collection. In order to guarantee serial access, it is
critical that all access to the backing collection is accomplished
through the returned collection."

"Thread safe" to znaczy ze wokol obiektu stawia sie proxy
synchronujace metody owego obiektu.

Thread safe nie znaczy Concurrent. Thread safe znaczy tylko tyle ze
dostep jest synchronizowany tak ze wiele watkow moze uzywac kolekcje.
Ale beda obslugiwane w kolejnosci, jedan watek at a time.

Jedyne kolekcje ktore sa concurrent znajduja sie w util.concurrent.

Wysukiwanie klucza w hash table jest operacja ktora posiada stan, wiec
rownolegly dostep do kolekcji wymagalby posiadania oddzielnej kopii
tego mechanizmu dla kazdego watku. Raczej watpie ze to ma miejsce.

Prosze poczytac tutaj

http://www.velocityreviews.com/forums/t126527-are-co
llections-synchronized-for-concurrent-reads.html

A.L.

P.S Natarczywosc Panskiego "domagania sie" powoduje ze przestaje mi
sie chciec odpowiadac. Moze przejdziemy na plaszczyzne profesjonalna,
tzn. consulting? Sytuacja bedzie wtedy bardziej klarowna: Pan placi,
Pan wymaga

do góry

On 1 Sie, 23:53, Piotr Lipski <l...@g...com> wrote:

> Jak wół stoi:
>
> "Like most collection classes, this class is not synchronized.

Zabawa polega na tym, że to nie jest takie proste.

Specyfikacja Javy (JLS) w rozdziale o wątkach a konkretnie o
współdzieleniu danych (17.4.1) pisze:

"Two accesses to (reads of or writes to) the same variable are said to
be conflicting if at least one of the accesses is a write."

Czyli wiele wątków *czytających* te same dane nie stanowi problemu.
Można stworzyć jakąś wartość (ogólnie: *strukturę danych*), zapewnić
jej widoczność i bez problemu czytać ją z wielu wątków. To jest
gwarantowane przez specyfikację języka.
BTW - stąd właśnie bierze się eksponowanie pomysłu na klasy
"immutable" w książce, którą polecał A.L. - obiekty niezmienne mogą
być używane przez wiele wątków równocześnie nie dlatego, że jest w
nich jakaś magia, tylko właśnie dlatego, że wtedy nie ma
konfliktujących zapisów.

W szczególności z tej gwarancji bierze się też pomysł na read-write
locks. One zapewniają odpowiednie relacje następstwa zdarzeń i
zapewniają też, że nie ma konfliktujących dostępów.
Ze specyfikacji języka wynika, że *KAŻDĄ* strukturę danych można
bezpiecznie czytać z wielu wątków, jeśli się zagwarantuje, że nie ma
konfliktujących zapisów.

Jeżeli piszesz kod sam, od zera, to wiesz, które operacje są odczytem
a które zapisem i stąd też wiesz, które z nich mogą być równoczesne.
Jeśli jednak używasz enkapsulowanych struktur danych (znanych również
jako kolekcje), to informacja o tym które operacje są modyfikujące a
które nie musi się znaleźć w dokumentacji.

Moje pytanie w pełnej wersji: czy get() w WeakHashMap jest operacją
modyfikującą? Jeżeli nie, to na mocy powyższego paragrafu można wołać
get() z różnych wątków (i w szczególności ReadWriteLock można użyć do
synchronizacji, wbrew temu, co twierdził A.L.).

*To* jest właśnie pytanie, któro tutaj zadałem.

Ale idźmy dalej. Zacytowałeś o WeakHashMap (A.L. zacytował to samo),
że:

"Like most collection classes, this class is not synchronized."

I tyle. Nic więcej. Może poszukamy analogii?
Jaka klasa kolekcji jest podobna do WeakHashMap? Może HashMap?
Z dokumentacji o HashMap:

"Note that this implementation is not synchronized. If multiple
threads access a hash map concurrently, *AND* at least one of the
threads *MODIFIES* the map structurally, it must be synchronized
externally."

Czyli jasno i wołami napisane, że klasa nie jest synchronizowana (tak
samo napisali o WeakHashMap) - ale napisali też, że synchronizacja
musi być zapewniona, jeśli jakiś wątek modyfikuje mapę w czasie gdy
inne ją czytają. A jeśli nie modyfikuje, to *nie musi*.

Oczywiście można pospekulować, że WeakHashMap jest potencjalnie
modyfikowana przez osobny wątek (przez GC). Ale wiemy też, że
modyfikacje wykonywane przez GC są bezpieczne (zresztą i tak nie
byłoby jak tych operacji synchronizować) i nie stanowią konfliktu z
wywołaniami funkcji get().

W skrócie:
1. Wiele wątków może czytać dowolną strukturę danych (patrz JLS).
2. Z dokumentacji WeakHashMap nie wynika, aby operacja get() była
modyfikatorem.

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ł?

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

do góry

On 1 Sie, 23:59, A.L. <a...@a...com> wrote:

> >Poproszę o cytat z dokumentacji wskazujący na niemożliwość czytania
> >WeakHashMapy z wielu wątków.
>
> Cytat: "Like most collection classes, this class is not synchronized.

To jeszcze nie wskazuje na niemożnośc czytania z wielu wątków -
dłuższą odpowiedź napisałem Piotrkowi Lipskiemu.

> Wysukiwanie klucza w hash table jest operacja ktora posiada stan, wiec
> rownolegly dostep do kolekcji wymagalby posiadania oddzielnej kopii
> tego mechanizmu dla kazdego watku.

Otóż nie i wiemy to choćby z JLS.
Moglibyśmy też stworzyć mapę immutable (jako wrapper na HashMap, która
jest wypełniania w konstruktorze) i jak to wyjaśniono w książce [*],
którą mi sam poleciłeś, ale najwyraźniej jej nie czytałeś, byłoby to
bezpieczne dla wielu wątków bez konieczności tworzenia osobnych kopii.

[*] Książka z pociągami, rozdział 3.4, strona 47:
"Immutable objects can still use mutable objects internally to manage
their state"

Przykład takiej klasy jest w listingu 3.11. Nie trzeba synchronizować
hash mapy do wyszukiwania klucza i nie trzeba robić jej wielu kopii.

> P.S Natarczywosc Panskiego "domagania sie" powoduje ze przestaje mi
> sie chciec odpowiadac.

Natarczywość mojego "domagania się" (btw - za każdym razem używałem
słowa "proszę", więc bez przesady z tym domaganiem) jest
proporcjonalna do Twojej natarczywości w propagowaniu błędnych
informacji. Czuję się usprawiedliwiony.

> Moze przejdziemy na plaszczyzne profesjonalna,
> tzn. consulting?

Nie, bez przesady. Mogę Ci wytłumaczyć wiele rzeczy i nie muszę brać
za to pieniędzy.
Nie psujmy dobrej usenetowej atmosfery.

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

do góry

> > Jak wół stoi:
>
> > "Like most collection classes, this class is not synchronized.
>
> Zabawa polega na tym, że to nie jest takie proste.
>
> Specyfikacja Javy (JLS) w rozdziale o wątkach a konkretnie o
> współdzieleniu danych (17.4.1) pisze:
>
> "Two accesses to (reads of or writes to) the same variable are said to
> be conflicting if at least one of the accesses is a write."

Z taką właśnie sytuacją mamy tu do czynienia. Szczegóły dalej.

> Czyli wiele wątków *czytających* te same dane nie stanowi problemu.
> Można stworzyć jakąś wartość (ogólnie: *strukturę danych*), zapewnić
> jej widoczność i bez problemu czytać ją z wielu wątków. To jest
> gwarantowane przez specyfikację języka.
> BTW - stąd właśnie bierze się eksponowanie pomysłu na klasy
> "immutable" w książce, którą polecał A.L. - obiekty niezmienne mogą
> być używane przez wiele wątków równocześnie nie dlatego, że jest w
> nich jakaś magia, tylko właśnie dlatego, że wtedy nie ma
> konfliktujących zapisów.

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

> Moje pytanie w pełnej wersji: czy get() w WeakHashMap jest operacją
> modyfikującą? Jeżeli nie, to na mocy powyższego paragrafu można wołać
> get() z różnych wątków (i w szczególności ReadWriteLock można użyć do
> synchronizacji, wbrew temu, co twierdził A.L.).
>
> *To* jest właśnie pytanie, któro tutaj zadałem.

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

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:

"Suppose that the garbage collector determines at a certain point in
time that an object is weakly reachable. [...] At the same time or at
some later time it will enqueue those newly-cleared weak references
that are registered with reference queues."

Jeśli obiekt jest "weakly reachable" to obiekt weak reference, który
go zawija trafia do kolejki (ReferenceQueue). Sprawdzamy kolejkę -
jeśli zawiera referencję to usuwamy je z mapy. Operacja usuwania może
być przeprowadzona w wątku, który wywołał jakąś operację na mapie (tak
się dzieje w przypadku java.util.WeakHashMap - wiem bo zajrzałem do
źródeł) może też być zrealizowane w sposób, który pokazał Michal
Kleczek - w odzielnym wątku "pollującym" kolejkę referencji.

Zarówno w pierwszej jak i drugiej implementacji mamy modyfikację mapy
w jednym wątku odczyt w drugim.

[...]

> 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ł?
>

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

PL

do góry

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

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

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

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

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

Nie jest.

do góry

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

Logiczna bzdura

A.L.

do góry

On Mon, 3 Aug 2009 01:03:08 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>
>Natarczywość mojego "domagania się" (btw - za każdym razem używałem
>słowa "proszę", więc bez przesady z tym domaganiem) jest
>proporcjonalna do Twojej natarczywości w propagowaniu błędnych
>informacji. Czuję się usprawiedliwiony.

Ja tez. Nie bede wiecej odpowiadal

A.L.

do góry