Wątek może posiadać 2 blokady?

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();
        
    }
    
}

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 :)

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/javase/7/docs/api/java/lang/IllegalMonitorStateException.html

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?

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ć.

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.

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".

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.

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

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?

W telegraficznym skrócie: wątek może wywołać obiekt.wait(), obiekt.notify() czy obiekt.notifyAll() tylko i wyłącznie wtedy, gdy jest wewnątrz jakiegoś bloku synchronized (obiekt). Monitory są reentrant, a więc możesz wejść do bloku synchronized(obiekt) będącego wewnątrz bloku synchronized(obiekt).

Taki kod jest całkowicie poprawny:

class Ideone {
	public static void main (String[] args)	{
		Object lock = new Object();
		synchronized(lock) {
			synchronized(lock) {
				System.out.println("Hello, World!");
			}
		}
	}
}

https://www.ideone.com/cFytv0

Przeczytaj mój pseudokod z postu powyżej ( Wątek może posiadać 2 blokady? ) ze zrozumieniem, a dostaniesz odpowiedzi na wszystkie swoje pytania związane z monitorami w Objectach :)

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.

Tak. Monitor zabezpiecza przed wejściem do danego kawałka kodu (ściślej: do wszystkich kawałków kodu synchronizowanych tym monitorem, bo tych kawałków kodu może być dowolna ilość), ale w żaden sposób nie wpływa na to jakie dane w tym kawałku kodu obrabiasz. Możesz mieć np popsutą wersję licznika z poprzedniego postu:

class Counter {
  int value = 0;
 
  int incrementAndGet() {
    synchronized(this) {
      value += 1;
      return value;
    }
  }
 
  int decrementAndGet() {
    value -= 1;
    return value;
  }
}

Synchronizacja w metodzie incrementAndGet jest daremna jeśli inne wątki będą sobie wykonywać niezsynchronizowaną metodę decrementAndGet. Powyższy kod jest technicznie poprawny pod względem wykorzystania synchronizacji i monitorów w tym sensie, że monitory są poprawnie pozyskiwane i oddawane, nie ma ma w tym kodzie jakichś deadlocków, livelocków czy tym podobnych. Podczas wywoływania metody incrementAndGet w jednym wątku inny wątek (lub inne wątki) może wywoływać metodę decrementAndGet. Nie spowoduje to żadnego wyjątku, ale z dużym prawdopodobieństwem spowoduje błędne wyniki działań na liczniku, zarówno w metodzie otoczonej synchronized(this) jak i tej nieotoczonej.

Podam jeszcze przykład na to, że monitor wcale nie musi chronić ani przed wielowątkowym dostępem do wspólnych danych ani przed wielowątkowym dostępem do wspólnego kodu. Wątki mogą mieć zupełnie różne dane i wykonywać zupełnie różny kod, ale dalej synchronizować się na monitorze. W poniższym kodzie wykorzystuję monitor współdzielony przez dwa wątki, by mogły naprzemiennie wypisywać powitania. Kod:

import java.util.*;
import java.lang.*;
import java.io.*;

public class Main {
	static class Thread1 extends Thread {
		Object lock;
		int counter = 10;
		
		@Override public void run() {
			try {
				synchronized(lock) {
					while (true) {
						System.out.println("Hello from Thread1!");
						lock.wait();
						counter -= 1;
						if (counter == 0) {
							return;
						}
						lock.notify();
					}
				}
			} catch (Exception ex) {
				throw new RuntimeException(ex);
			}
		}
	}
	
	static class Thread2 extends Thread {
		Object lock;

		@Override public void run() {
			try {
				synchronized(lock) {
					lock.notify();
					while (true) {
						System.out.println("Hello from Thread2!");
						lock.wait();
						lock.notify();
					}
				}
			} catch (Exception ex) {
				throw new RuntimeException(ex);
			}
		}
	}
	public static void main (String[] args) throws Exception {
		Object sharedLock = new Object();
		Thread1 thread1 = new Thread1();
		Thread2 thread2 = new Thread2();
		thread1.lock = sharedLock;
		thread2.lock = sharedLock;
		thread1.start();
		Thread.sleep(123);
		thread2.start();
		thread1.join(1234);
		thread2.interrupt();
		thread2.join();
	}
}

Wynik:

Hello from Thread1!
Hello from Thread2!
Hello from Thread1!
Hello from Thread2!
Hello from Thread1!
Hello from Thread2!
Hello from Thread1!
Hello from Thread2!
Hello from Thread1!
Hello from Thread2!
Hello from Thread1!
Hello from Thread2!
Hello from Thread1!
Hello from Thread2!
Hello from Thread1!
Hello from Thread2!
Hello from Thread1!
Hello from Thread2!
Hello from Thread1!
Hello from Thread2!

https://www.ideone.com/DgIPv3

Gdybyś po prostu przeanalizował pseudokod, który ci przygotowałem to nie byłoby to dla ciebie nic dziwnego.