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