Wątek może posiadać 2 blokady?

Odpowiedz Nowy wątek
2019-01-17 17:00
1

Witam

W poniższym kodzie wywołuje metodę synchronized, która zakłada blokadę na obiekt R2. Wewnątrz tej metody zakładam kolejną blokadę wewnątrz bloku synchronized na inny obiekt. Program działa tak jak powinien i jestem zaskoczony. Co de facto się dzieje wewnątrz metody run obiektu R2? Jeżeli zamiast synchronized(r1) napiszę synchronized(this) program wyrzuci wyjątek IllegalMonitorStateException. Rozumiem to tak, że poprzez wywołanie metody run() obiekt R2 zyskuje dla siebie blokadę. Następnie w ciele metody wywołuje wywołuje blok synchronizowany względem obiektu r1 czyli obiekt R2 ma 2 blokady?

class R1 implements Runnable {
    { Thread.currentThread().setName("R1"); }
    @Override synchronized public void run() {
       try {
           while(true){
               Thread.sleep(5000);
               System.out.println("zadanie R1 start()");
               wait();
            }
       }
       catch(InterruptedException e) {
           System.out.println("przerwanie: " + e);
       }
       System.out.println("R1 wyjscie z wait()");
    }
}

class R2 implements Runnable {
    { Thread.currentThread().setName("R2"); }
    private R1 r1;
    public R2(R1 r1) {
        this.r1 = r1;
    }
    @Override synchronized public void run() {
       try {
           while(true) {
               System.out.println("zadanie R2 start");
               Thread.sleep(5000);

               synchronized(r1) {           //  synchronized(this) nie działa  - zglasza wyjatek IllegalMonitorStateException. 
                   r1.notify();
               }
           }
       }
       catch(InterruptedException e) {
           System.out.println("przerwanie R2: " + e);
       }
       System.out.println("R2 wyjscie z wait()");
    }
}

public class WaitNotifyTest {

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) throws Exception {

        FLAG flag = new FLAG(true);

        R1 r1 = new R1();
        R2 r2 = new R2(r1);
        ExecutorService exec = Executors.newCachedThreadPool();

        exec.execute(r1);
        Thread.sleep(1000);
        exec.execute(r2);

        exec.shutdown();

    }

}
edytowany 1x, ostatnio: Kuben, 2019-01-17 17:00

Pozostało 580 znaków

2019-01-17 17:56
1

synchronized na metodzie niestatycznej, to synchronized(this). W R2 masz dwie blokady o różnym zakresie. Swoją drogą robienie synchronizowanego run mija się z celem :)

Pozostało 580 znaków

2019-01-17 18:49
0

Mam dwie blokady ale odnoszące się do tego samego obiektu R2? Tzn. że działa to trochę jak w przypadku Lock, czyli że jeżeli wywołamy kilkukrotnie lock() w run() to zwiększa się licznik blokad i zostanie ona ostatecznie zwolniona gdy wywołamy taką samą ilość unlock() w metodzie run? Co znaczy że blokady mają różny zakres?

Pozostało 580 znaków

2019-01-17 19:07
0

Po kolei.

Blokady mają różny zakres, oznacza, że monitor na this (wynikający z synchronized na metodzie) blokuje inny kod niż ten na r1.

W twoim kodzie próbujesz wywołać notify na r1, ale żeby to zrobić musisz posiadać monitor na r1 (czyli synchronized(r1)). Jeżeli zmienisz na synchronized(this), to masz podwójną blokadę (nie ma licznika jako takiego), ale nie możesz wywołać notify na r1. Patrz dokumentacja wyjątku → https://docs.oracle.com/javas[...]galMonitorStateException.html

edytowany 1x, ostatnio: Koziołek, 2019-01-17 19:11

Pozostało 580 znaków

2019-01-17 19:25
0

To może cofnijmy się jeszcze bardziej:

  1. Blokada oznacza że dany wątek może mieć jako jedyny dostęp do zasobu i inny wątek nie może w tym samym czasie korzystać z tego samego zasobu, tak?
  2. Argument bloku synchronized jest to argument względem którego przeprowadzana jest synchronizacja, co nie oznacza że ten właśnie obiekt pozyskuje blokadę, tak? Tzn. że dwa wątki synchronizując swój dostęp względem różnych obiektów X1 i X2 do tego samego zasobu będą miały jednoczesny dostęp do tego zasobu, zgadza się?

No i tu mi się coś nie zgadza, ponieważ wydawało mi się że tam gdzie pojawi się blok synchronized tam zakładana jest blokada, czyli jeżeli słowo synchronized pojawia się w metodzie run() obiektu R2, to drugi raz zakładana jest blokada na obiekt R2 tyle że inna bo synchronizowana wedle obiektu r1 a nie this, ale sam obiekt r1 nie zyskuje blokady. Czyli wedle tego rozumowania powinno wywalać wyjątek zarówno wtedy gdy synchronizuje według r1 jak i this, bo blokadę ma ciągle r2 ( r2 nie wywołało wait() by pozbyć się swojej blokady). Gdzie popełniam błąd w rozumowaniu?

edytowany 2x, ostatnio: Kuben, 2019-01-17 19:28

Pozostało 580 znaków

2019-01-17 19:46
0
  1. Zależy. Generalnie blokada zabezpiecza przed wykonaniem fragmentu kodu przez inne wątki, gdy wykonuje go już jakiś wątek. W szczególności uniemożliwia wykonywanie metod na obiekcie przez więcej niż jeden wątek naraz. Dzięki temu możesz faktycznie zablokować współbieżny dostęp do jakichś zasobów.
  2. To nie obiekt pozyskuje blokadę. Blokadę pozyskuje wątek. Zamknięcie blokady na obiekcie powoduje, że inne wątki nie będą mogły również założyć blokady na tym samym obiekcie (z pewnymi wyjątkami tzn read locks), zatem jeśli jakiś fragment kodu zamknięty jest w bloku synchronized czy poprzedzony zamknięciem zamka na obiekcie, będą musiały czekać aż blokada się zwolni zanim będą mogły go wykonać.

Blocker wiszący od miesiąca? Mówisz o tym criticalu z zeszłego tygodnia? A, tak, zalogowaliśmy przedwczoraj tego minor buga. Pewnie, zajmę się ASAP tym enhancementem. Nie ma sprawy, jak tylko podomykam taski to wezmę się za ten ficzer, tylko go jeszcze wyestymujemy przed kolejnym sprintem.
edytowany 1x, ostatnio: superdurszlak, 2019-01-17 19:47

Pozostało 580 znaków

2019-01-17 20:07
5

Obiekty nie pozyskują blokady. Każdy obiekt posiada własny monitor, a wątki pozyskują te monitory. W sekcji synchronized wątek może wywołać metodę wait() na monitorze i tym samym oddać go komuś innemu, a precyzyjniej czekać aż inny wątek wywoła notify() na tym monitorze (wcześniej go oczywiście pozyskując) z tym, że w ogólności nie ma gwarancji który wątek zostanie wzbudzony po wywołaniu notify().

Koncepcyjnie możesz to sobie wyobrazić jako klasę:

class Monitor {
  Optional<Thread> currentThread = Optional.empty();
  int currentThreadCounter = 0;
  LinkedMap<Thread, Integer> waitingThreads = new LinkedMap<>();
  LinkedMap<Thread, Integer> notifiedThreads = new LinkedMap<>();
}

której jedną instancję posiada każdy obiekt. Dla uproszczenia załóżmy, że klasa Object zawiera pole Monitor (ale Monitor nie rozszerza Object, bo wtedy byłaby nieskończona rekurencja):

class Object {
  final Monitor monitor = new Monitor();
  void wait() { ... }
  void notify() { ... }
  void notifyAll() { ... }
}

Wejście do synchronized (obiekt) robi mniej więcej taką rzecz:

  • jeśli obiekt.monitor.currentThread jest puste to ustaw na obecny wątek i ustaw licznik na 1
  • jeśli obiekt.monitor.currentThread istnieje i jest równy obecnemu wątkowi to zwiększ obiekt.monitor.currentThreadCounter o 1
  • jeśli obiekt.monitor.currentThread istnieje, ale oznacza inny wątek to dodaj się do mapy oczekujących wątków z licznikiem 1 i zatrzymaj wątek

Wyjście z synchronized (obiekt) zmniejsza licznik o 1 i jeśli zostanie wyzerowany to czyści pole obiekt.monitor.currentThread oraz przenosi jeden wątek (o ile taki istnieje) z obiekt.monitor.notifiedThreads do obiekt.monitor.currentThread (włącznie z licznikiem). Przeniesiony wątek jest następnie wybudzany.

Wywołanie metody obiekt.wait() sprawdza czy obiekt.monitor.currentThread jest równy obecnemu wątkowi i:

  • jeśli nie to rzuca wyjątek,
  • jeśli tak to przenosi obecny wątek ze zmiennej obiekt.monitor.currentThread do mapy obiekt.monitor.waitingThreads i zatrzymuje wątek. Jeśli kolekcja obiekt.monitor.notifiedThreads jest niepusta to przenosi jeden wątek z niej do obiekt.monitor.currentThread i wznawia ten wątek.

Wywołanie metody obiekt.notify() sprawdza czy obiekt.monitor.currentThread jest równy obecnemu wątkowi i:

  • jeśli nie to rzuca wyjątek,
  • jeśli tak to przerzuca jeden wątek z obiekt.monitor.waitingThreads do obiekt.monitor.notifiedThreads

Wywołanie metody obiekt.notifyAll() sprawdza czy obiekt.monitor.currentThread jest równy obecnemu wątkowi i:

  • jeśli nie to rzuca wyjątek,
  • jeśli tak to przerzuca wszystkie wątki z obiekt.monitor.waitingThreads do obiekt.monitor.notifiedThreads

Bardzo możliwe, że coś grubo pokręciłem ale mniej więcej tak to działa.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 8x, ostatnio: Wibowit, 2019-01-17 21:23
Wow, chyba zacznę brać witaminy :-) - cs 2019-01-17 20:39

Pozostało 580 znaków

2019-01-17 20:49
0

Chciałbym rozróżnić pojęcie wątek i zadanie, które wykonuje ten wątek (a które to zadanie może kontynuować w połowie jakiś inny wątek). Czy dobrze rozumiem?:

  1. wait() zawiesza wykonanie zadania, poprzez zwolnienie blokady monitora obiektu X, który wykonywał właśnie część zadania - obiektem tym operował wątek A.
  2. Następnie wątek A pozbywa się blokady monitora obiektu X na którym pracował, który jest częścią zadania - wątek A przechodzi do stanu zablokowany.
  3. Inny DOSTĘPNY (w stanie GOTOWY) wątek B przejmuje blokadę monitora obiektu X - wykonuje na nim jakieś operacje nie związane z poprzednim zadaniem a następnie wywołuje metodę X.notifyAll().
  4. Uśpione wątki (będące w stanie ZABLOKOWANY), wybudzają się i przechodzą w stan GOTOWY.
  5. Gdy tylko wątek B odda blokadę monitora, wybudzone wątki rozpoczynają wyścig po blokadę monitora obiektu X.
  6. Zadanie jest wznawiane przez jakiś zwycięski wątek C.

"[..]a precyzyjniej czekać aż inny wątek wywoła notify() na tym wątku (wcześniej go oczywiście pozyskując) [..]" Zamiast "wątku" nie powinno być: "obiekcie".

Pozostało 580 znaków

2019-01-17 21:22
0

Gdy tylko wątek B odda blokadę monitora, wybudzone wątki rozpoczynają wyścig po blokadę monitora obiektu X.

Nie ma żadnego wyścigu. Po prostu wybudzany jest jeden z powiadomionych (notified) wątków.

Ogólnie niepotrzebnie komplikujesz sobie rozumowanie jakimiś zadaniami (co to w ogóle jest?) i tym, że synchronizowanie się na danym obiekcie jest wtedy i tylko wtedy, gdy dokładnie na nim chcemy operować. Popatrz na ten kod:

class Counter {
  final Object lock = new Object();
  int value = 0;
 
  int incrementAndGet() {
    synchronized(lock) {
      value += 1;
      return value;
    }
  }
 
  int decrementAndGet() {
    synchronized(lock) {
      value -= 1;
      return value;
    }
  }
}

Dowolna ilość wątków może wywoływać metody incrementAndGet oraz decrementAndGet w dowolnej kolejności. Może być tak, że 5 wątków czeka w metodzie incrementAndGet, a 10 wątków czeka w metodzie decrementAndGet w tym samym obiekcie. Kod jest poprawnie zsynchronizowany i mamy gwarancję, że w danym momencie wartość licznika jest równa ilości skończonych wywołań incrementAndGet minus ilości skończonych wywołań decrementAndGet.

Nie wiem dokładnie o co ci chodziło z zadaniami, ale w momencie gdy wątek wraca z metody wait() jest stos wygląda dokładnie tak samo jak wtedy gdy wchodził do metody wait(). Na stosie jak wiadomo mamy ramki stosu, które zawierają zmienne lokalne oraz adresy powrotu. Podobnie ma się sprawa ze wskaźnikiem instrukcji - wejście do metody wait() w linijce 100 nie sprawi, że powrót z metody wait() będzie w linijce np 50. Miejsce powrotu będzie tuż po tej instrukcji wait(), która spowodowała czekanie.

"[..]a precyzyjniej czekać aż inny wątek wywoła notify() na tym wątku (wcześniej go oczywiście pozyskując) [..]" Zamiast "wątku" nie powinno być: "obiekcie".

Poprawiłem. Dzięki.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 2x, ostatnio: Wibowit, 2019-01-17 21:33
"Kod jest poprawnie zsynchronizowany i mamy gwarancję, że w danym momencie wartość licznika jest równa ilości skończonych wywołań incrementAndGet minus ilości skończonych wywołań decrementAndGet." - Nie brakuje volatile? - nut 2019-01-17 23:03
Myślę, że nie, bo cały kod mający dostęp do value jest otoczony synchronized. No chyba, że ktoś będzie się dobierał do value bezpośrednio - wtedy volatile się przyda. Wyjaśnienie np tutaj: https://dzone.com/articles/ja[...]latile-variables-happens-be-1 na końcu w pytaniu: I Notice That the Synchronized Version Does Not Mark the Counter as Volatile. Does This Mean…? - Wibowit 2019-01-17 23:09
Synchronized wymusza aktualizacje main memory więc modyfikacja przez wątek A zmiennej value będzie rowniez odczytana przez wątek B. - Kuben 2019-01-18 07:49

Pozostało 580 znaków

2019-01-17 21:30
0

@Kuben: swoją drogą dlaczego korzystac wait/nofify jak ma się Condition?


Nie pomagam przez PM. Pytania zadaje się na forum.
edytowany 1x, ostatnio: scibi92, 2019-01-17 21:30

Pozostało 580 znaków

2019-01-17 22:16
0
Wibowit napisał(a):

Gdy tylko wątek B odda blokadę monitora, wybudzone wątki rozpoczynają wyścig po blokadę monitora obiektu X.

Nie ma żadnego wyścigu. Po prostu wybudzany jest jeden z powiadomionych (notified) wątków.

Ogólnie niepotrzebnie komplikujesz sobie rozumowanie jakimiś zadaniami (co to w ogóle jest?) i tym, że synchronizowanie się na danym obiekcie jest wtedy i tylko wtedy, gdy dokładnie na nim chcemy operować.

Przez zadanie rozumiem zawartosć metody run() czy to implementowaną dla obiektu Thread czy interfejsu Runnable. Czyli watęk wykonujący blok synchronized uzyskuje blokade obiektu jaki zostal przekazany do bloku synchronized jako argument. Obiek ten sluzy jako klucz dostępu do kodu zawartego w bloku, tak? A kod w bloku moze nie mieć nic wspólnego z tym obiektem. Teraz już rozumiem moj błąd. Nie moglem użyc synchronized(this) wywołujac metodę r1.notify() ponieważ w ten sposob zakladalem drugą blokade na obiekt r2 I nic poza tym, a tymczasem wywołanie notify() wymaga blokady obiektu na rzecz którego się tą metodę wywołuje. Chyba dobrze już rozumiem, prawda?

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0