Dzialanie deadlocka

Dlaczego w podanym kodzie nie wystepuje deadlock? Najpierw wywoluje i metode getC() i ja blokuje (podobno niejawnie, kluczem ktory jest tylko jeden na instancje) -> wywoluje metode z innej klasy, ktora wywoluje metode z pierwszej klasy, ktorej metoda getC() jest juz 'zablokowana' wiec jakim sposobem dostano sie do metody getC2(), skoro klucz jest aktualnie wykorzystywany przez getC()?

public class Main {

    public static void main(String[] args) {
        Foo foo = new Foo();
        Foo2 foo2 = new Foo2(foo);
        foo.setFoo(foo2);

        System.out.println(foo2.getC());
    }

}

class Foo2{
    Foo foo;
    public Foo2(Foo foo){
        this.foo = foo;
    }
    public synchronized int getC(){
        return foo.getB();
    }

    public synchronized int getC2(){
        return 33;
    }
}

class Foo{

    private Foo2 foo2;

    public synchronized int getB(){
        return foo2.getC2();
    }
    
    public void setFoo(Foo2 foo2) {
        this.foo2 = foo2;
    }
}

Tak działają monitory. To WĄTEK po przejściu przez synchronized staje się właścicielem monitora/blokady i kolejne przechodzenie tego samego wątku przez synchronized do tego samego monitora nie powoduje problemów - jvm wie, że tego pana już zna i on tu chwilowo rządzi. Tak samo jakbyś od razu z getC() wywołał getC2() lub nawet rekurencyjnie getC().

To się nazywa Reentrancy .

i wszystko jasne, dzieki!

Deadlock nie może wystąpić przy jednym wątku. Trochę mnie to rozbawiło :) Musisz przedstawić przykład z 2 wątkami jednocześnie, dopiero wtedy jest szansa na deadlock.

jarekczek napisał(a):

Deadlock nie może wystąpić przy jednym wątku.

Dla chcącego nic trudnego:

public static void main(String args[])throws Exception {
       new java.util.concurrent.Semaphore(1).acquire(2);
       
        System.out.println("koniec bajki");
    }

Chętnie przyznałbym Ci rację, bo ten przykład też jest zabawny. Ale niestety definicja mówi o blokadzie wzajemnej (waiting for some other member). Przykro mi. Nie możemy uprawiać dezinformacji :)

jarekczek napisał(a):

Chętnie przyznałbym Ci rację, bo ten przykład też jest zabawny. Ale niestety definicja mówi o blokadzie wzajemnej (waiting for some other member). Przykro mi. Nie możemy uprawiać dezinformacji :)

A gdzie jest napisane że "other-member" - to inny wątek ? przecież nawet JCIP pisze

Reentrancy facilitates encapsulation of locking behavior, and thus simplifies the development of object-oriented concurrentcode. Without reentrantlocks, the very natural-looking code in Listing 2.7, in which a subclass overrides a synchronized method and then calls the super class method, would deadlock.

Czyli jeden wątek który w jednej metodzie pobiera locka na Locku który jest nie-reentrant (nie gawaryt po polszy tutaj) i robi to samo w drugiej, chapie deadlock. @jarekr000000 ma racje - chyba że, uwaga, człowiek z książki o pociągach też źle definiuje pojęcie deaclocku, w takim razie masz racje.

P.S tak, zQ@#jabełm ten kawałek ze stackoverflow i się tego nie wstydzę.