Tak w sumie zastanawiam się czy mając do dyspozycji kolekcje z java.util.concurrent używanie locków ma jakiś sens?
W sumie przecież skoro mamy volatile i AtomicReference + immutable object to locki wydają się "gorszym" rozwiązaniem?
1
1
Volatile samo z siebie nie zapewnia bezpiecznej aktualizacji. AtomicReference zapewnia bezpieczną aktualizację, ale to tylko referencja. Lock pozwala na blokowanie zasobu, ale też budowę sekcji krytycznej przez kilka poziomów. Pozwala też wprowadzić różne poziomy izolacji jak np. ReadWriteLock.
0
No tak @Koziołek masz rację, ale jeśli to referencja na Immutable Object to z tego co mi wiadomo jest to threadsafe.
No bo tak -> AtomicReference jest współdzielony. Sama obiekt wskazywany nie jest koniecznie bezpieczny, ale referencja jest. Ale skoro to referencja na obiekt niemutowalny to już mamy threadsafe :)
0
Jest dokładnie jak piszesz. Chyba, że masz dwa obiekty niemutowalne :-).
Ale dokładnie z tego powodu zawsze najlepiej jest mieć co najwyżej jeden współdzielony obiekt (immutable) w danym kontekście.
0
@scibi92: byt niezmienny z definicji jest bezpieczny, bo nikt go nie może zmienić. Problem pojawia się gdy jak pisze @jarekr000000 masz dwa takie obiekty w kontekście, albo jeszcze lepiej masz jakiś ograniczony zasób. Wtedy Lock zapewnia odpowiednią elastyczność.
0
A no w sumie racja :)
0
W typowym biznesowym kodzie starczą immutable, kolekcje na JavaSlang/Vavr i volatile/ AtomicRef.
Locki się raczje przydadzą jeśli walczysz o cykle : symulacje (również ML), gry/grafika, niskopoziomowe walki z IO.
0
jarekr000000 napisał(a):
W typowym biznesowym kodzie starczą immutable, kolekcje na JavaSlang/Vavr i volatile/ AtomicRef.
Locki się raczje przydadzą jeśli walczysz o cykle : symulacje (również ML), gry/grafika, niskopoziomowe walki z IO.
I tak, i nie :)
W core'owych systemach locki przydają się jak najbardziej (głównie rozdzielanie zasobów i udziwnione transakcje - np. jeśli otwarto transakcję i zawołano cośtam z parametrem A to trzy niepowiązane zasoby X, Y, Z powinny zostać zalockowane, w przypadku parametru B tylko X, Y itp.). Zwłaszcza jeśli to jest jakaś stara kobyła.
W backendach służących do ogarniania formularzy faktycznie Immutable zapewnia stabilność.
1
scibi92 napisał(a):
Tak w sumie zastanawiam się czy mając do dyspozycji kolekcje z java.util.concurrent używanie locków ma jakiś sens?
W sumie przecież skoro mamy volatile i AtomicReference + immutable object to locki wydają się "gorszym" rozwiązaniem?
Oceniasz coś jako "gorsze" bez wskazania kryterium :) Możesz gdybać, bo nie masz podanego konkretnego problemu i zastanawiasz się czy jedno narzędzie jest lepsze od innego. To tak jakbyś pytał po co młotek, skoro masz wiertarkę.
Przykładowe różne problemy, w których możesz rozważać różne narzędzia synchronizacji.
Problem#1 - zapis do pliku przez różne wątki, po co Ci kolekcje w tym przypadku?
Problem#2 - wywołanie metody obiektu, która operuje na części stanu obiektu, ale nie na całym stanie?
Problem#3 - konsumpcja danych z kolejki przez kilka wątków
...
0
yarel napisał(a):
scibi92 napisał(a):
Tak w sumie zastanawiam się czy mając do dyspozycji kolekcje z java.util.concurrent używanie locków ma jakiś sens?
W sumie przecież skoro mamy volatile i AtomicReference + immutable object to locki wydają się "gorszym" rozwiązaniem?Oceniasz coś jako "gorsze" bez wskazania kryterium :) Możesz gdybać, bo nie masz podanego konkretnego problemu i zastanawiasz się czy jedno narzędzie jest lepsze od innego. To tak jakbyś pytał po co młotek, skoro masz wiertarkę.
Przykładowe różne problemy, w których możesz rozważać różne narzędzia synchronizacji.
Problem#1 - zapis do pliku przez różne wątki, po co Ci kolekcje w tym przypadku?
Problem#2 - wywołanie metody obiektu, która operuje na części stanu obiektu, ale nie na całym stanie?
Problem#3 - konsumpcja danych z kolejki przez kilka wątków
...
Problem #2 można rozwiązać przez AtomicReference wewnątrz obiektu.
Problem #3 nie jest przecież problemem, wiadomości z kolejki powinny być z zasady Immutable, ewentualnie każdy wątek powinien mieć swoją kopię. Chyba, że te wątki działają na jeszcze innych współdzielonych zasobach - ale wtedy kolejka nie jest problemem.
0
3 Przecież BlockingQueue jest threadsafe
0
Przy immutable objects trzeba pamiętać jeszcze żeby nie być kretynem i nie publikować obiektów w konstruktorze (np wpinać ich jako listenery). JLS podchodzi w wielu miejscach bardzo liberalnie co do tego gdzie można sobie pozmieniać kolejność wywoływania instrukcji, i wasz niemutowalny obiekt może nie być zainicjalizowany w momencie zgłoszenia czegoś przez obserwowany obiekt.