Przewaga ReentrantReadWriteLock na zwyklymi Lockami?

Czesc, na wstepie przeraszam za brak polskich znakow.

Przerabiam pakiet java.util.concurrent, trafilem na klase ReentrantReadWriteLock. Obiekt posiada 2 Locki :

• readLock - zakladany gdy odczytuje, czytac moze wiele watkow, pisac zaden.
• writeLock - lockowany tylko przez jeden watek (nie wiecej), ktory modyfikuje obiekt

Zakladajac locka w metodzie dostepowej kilkukrotnie - licznik (readLocka) sie inkrementuje, zupelnie jak w ReentrantLocku.
Natomiast w metodzie modyfikujacej jak rozumiem (w co szczerze watpie) moge tylko raz wywolac lock() - zatem tylko jeden watek bedzie mial dostep.

Pytanie - Interesuje mnie, jaka jest przewaga zastosowania ReentrantReadWriteLock nad dwoma ReentrantLock'ami ?

Wybierajac wariant dwoch ReentrantLock'ow by zapewnic synchronizacje musialbym sprawdzac za kazdym czy jeden z lockow nie jest zajety by zapewnic synchronizacje, zas w pierwszym przypadku zostaje wyreczony?

Mozecie mnie poprawic?

Załóżmy, bardzo pozytywnie, że masz dwa locki i dwa wątki. Wątek A chce czytać i pisać, wątek B czytać i pisać. Wątek B zakłada ReadLocka. Wątek A zakłada ReadLocka. Wątek B chce po odczytaniu zmienić wartość i zakłada, próbuje, WriteLocka - musi czekać co i robi. W tym samym czasie wątek A chce pisać i próbuje założyć WriteLocka. Nie może, bo B trzyma ReadLocka i czeka na zwolnienie przez A...

Sytuacja nie jest wbrew pozorom niezwykła, bo będzie to wielowątkowa implementacja mechanizmu w którym zależy nam na odczycie i nadpisaniu pewnej wartości. I zrobieniu tego na wyłączność. Do tego używamy tu dwóch locków i mamy problem...

W przypadku ReentrantReadWriteLock posiadasz jeden obiekt, który będzie synchronizował odczyt i zapis i będzie współdzielony przez wiele wątków. Choć osobiście uważam, że i tak użyjesz go źle ;) Pisanie softu wielowątkowego jest po prostu trudne.

Dzieki za odpowiedz ;) Pisanie wielowotkowo jest trudne, ale trzeba dazyc by umiec jak najwiecej. Bo Pan Seliga nakrzyczy ;)

Pan Seliga sobie może krzyczeć... who cares... W praktyce jak chcesz coś więcej dowiedzieć się o tym jak dobrze rozwiązać tego typu problem to poszukaj informacji o Software Transactional Memory i implementacji tego mechanizmu w Clojure oraz o tym jak tego użyć z Javy (banalnie proste).

Koziołek napisał(a):

Pan Seliga sobie może krzyczeć... who cares... W praktyce jak chcesz coś więcej dowiedzieć się o tym jak dobrze rozwiązać tego typu problem to poszukaj informacji o Software Transactional Memory i implementacji tego mechanizmu w Clojure oraz o tym jak tego użyć z Javy (banalnie proste).

Ja bym jednak polecał lekturę jsr-133 i Java concurrency in practice Briana Goetza

@wojciech.kudla, lektura jsra i książek to jest osobna sprawa. Tu mówimy o czymś zupelnie innym ;)

Książka o wielowątkowości w Javie, która moim zdaniem daje rade:

http://helion.pl/ksiazki/java-wspolbieznosc-dla-praktykow-zespol-autorow,javwsp.htm

I jest po polsku co akurat w temacie wielowątkowosci jest dużym plusem.

lipkerson napisał(a):

I jest po polsku co akurat w temacie wielowątkowosci jest dużym plusem.

Polskojezyczna literatura w z Javy to jakiś żart. Pomijając fakt że polskie wydania pojawiają się w momencie jak dana technologia zaczyna się już przedawniac, to pozostaje jeszcze kwestia nieudolnych tłumaczeń terminów. Moje ulubione to odsmiecacz i pyłek. Jak potem czytając anglojęzyczne materiały odnieść to do czegokolwiek?
Jeśli nie chcesz ograniczyć się do poziomu średnio ogarnietego klepacza to nie powinieneś czerpać wiedzy z polskojezycznej literatury.