Poprawne zsynchronizowanie metody.

Witam, czytam o synchronizacji i naszła mnie myśl na mały program.

Otóż załóżmy że mamy klasę

Account:

• saldo

• getSaldo()
• withdraw(amount)
• add(amount)

BankOperation:
+transfer(Account from,Account to,double amount)

I będziemy z nich korzystać w taki sposób, że na cały system mamy wiele obiektów Account i jeden obiekt typu BankOperation, który zajmuje się przelewaniem środków.

Załóżmy, ze mamy interfejs który wywołuje zdarzenia przelewania pieniędzy pomiędzy danymi kontami. I teraz jeżeli ktoś by wywołał operacje (A,B) i w tym samym czasie ktoś inny (B,C) to następuje dostęp do B przez 2 wątki. I tu trzeba zastosować blokowanie,warunki -> synchronizacji. I tu pojawia się moje pytanie, czy wystarczy zalożyć synchro na metode BankOperation:transfer?

jesli stan obiektow Account jest zmieniany tylko w metodzie transfer to tak, wystarczy

Gdyby istniał drugi obiekt klasy BankOperation i tez wykonywał transfer to wtedy już nie da nam to bezpieczeństwa?

musialbys synchronizacje oprzec na tym samym lock'u

Pamiętam że nie tylko dostęp powinien być synchronizowany - czytanie także - bo synchronized to nie tylko lock który gwarantuje dostęp tylko z jednego wątku - ale też gwarantuje ci że zapis do zmiennej widocznej dla innych wątków, będzie dla nich "aktualny". także czytanie też musi być synchronizowane.

Badz volatile - jesli to tylko getter zmiennej, to wystarczy, nie trzeba synchronizowac.

Jasne, także prawidłowe podejście - ale jeżeli tych czytań nie ma tak dużo - brak cacha przez volotile może być rekompensowany właśnie przez synchronizowany getter

Czytalem kiedys ze od Javy 5 i nowego memory model nie ma wielkiej roznicy miedzy volatile i synchronized. Wczesniej mowilo sie ze volatile jest szybsze bo nie wymaga brania monitora itp. ale od jdk5 sie wyrownalo. Z doswiadczenia jednak wiem, ze ludzie nie wiedza co to volatile, wiec chcialem dac wskazowke.

Czekaj czekaj - **volotile **i **synchronized **to ZUPEŁNIE dwie różne rzeczy - mają tylko jedną wspólną cechę - oba zawiązują z wywołującym happens-before-relationship - i to właśnie skutuję widocznością i brakiem stale-data.

JDK nie ma tu za wiele do rzeczy, bo np: JMM, zależy od procesora, systemu - czyli jakie bariery znajdują się pod spodem.