Probleme mit Deadlock-Beispiel

[hdi]

Hey, ich suche im Moment ein gutes Bsp für ein Deadlock. Es gibt im Inet zwar genügend Code-Examples, und ich sehe auch die Deadlocks darin, finde aber irgendwie dass die Beispiele an sich schon total künstlich konstruiert sind durch scheinbar willkürliches synchen von Methoden..
Das einzige was mir im Moment von einem Anwendungsfall in der Praxis einleuchtet ist das Philosophen-Problem. Allerdings ist das ziemlich komplex und ich frage mich ob es da nicht auch ein primitiveres Bsp gibt. Nun bei meiner Suche bin ich auf das von Sun gestoßen:

(Bem.: Es geht hier um eine Begrüßung von zwei Freunden durch Verbeugen, nicht ums Bogenschiessen Ist euch vllt klar aber ich hab das erstmal nich gerafft und dachte an ein RPG-Game oder so^^)

Alphonse and Gaston are friends, and great believers in courtesy. A strict rule of courtesy is that when you bow to a friend, you must remain bowed until your friend has a chance to return the bow. Unfortunately, this rule does not account for the possibility that two friends might bow to each other at the same time. This example application, Deadlock, models this possibility:

 public class Deadlock {
        static class Friend {
            private final String name;
            public Friend(String name) {
                this.name = name;
            }
            public String getName() {
                return this.name;
            }
            public synchronized void bow(Friend bower) {
                System.out.format("%s: %s has bowed to me!%n", 
                        this.name, bower.getName());
                // (1)
                bower.bowBack(this);
            }
            public synchronized void bowBack(Friend bower) {
                // (2)
                System.out.format("%s: %s has bowed back to me!%n",
                        this.name, bower.getName());
            }
        }

        public static void main(String[] args) {
            final Friend alphonse = new Friend("Alphonse");
            final Friend gaston = new Friend("Gaston");
            new Thread(new Runnable() {
                public void run() { alphonse.bow(gaston); }
            }).start();
            new Thread(new Runnable() {
                public void run() { gaston.bow(alphonse); }
            }).start();
        }
    }

So, also ein Deadlock kann auftreten - ja. Aber ich verstehe das Beispiel nicht. Warum sind die Methoden überhaupt synchronized? Ich meine ohne synch kann bei (2) geswitcht werden, was dann zu einem selstsamen Programmablauf fürhen würde.
Aber mit synch kann halt bei (1) geswitcht werden, das sind lediglich paar nanosekunden vorher und der Programmablauf würde genauso in etwas Sinnlosem enden :bahnhof:

Meine Frage also: Warum sind die Methoden synchronisiert? Ich finde das Programm hat ne Logik die nicht das erfüllt was im Text zum Beispiel gesagt wird, und irgendwie könnten da jetzt ohne sync soviele Race Conditions knallen wie sie wollen, es würde den Ablauf nicht verändern. (Bzw das synchen stellt nicht sicher dass nicht genau der selbe Mist passiert)

 

[eRaaaa]

Mhm? Das Beispiel soll ja gerade zeigen, dass es so zu einem Deadlock kommen kann....gerade weil die Methoden synchronized sind ???:L

sync:
Gaston: Alphonse has bowed to me!
Alphonse: Gaston has bowed to me!
(nun wartet jeder Thread auf den anderen bei bowBack...--> Deadlock!!!)

 

[hdi]

Ja das is schon klar, aber ich meine eig. geht es ja im Endeffekt darum zu zeigen wie und wo man wait() und notify() verwendet, um das Problem zu lösen. Genauso wie man synchronized nur verwendet wenn man 2 Threads hat die gemeinsam auf einer Resource arbeiten - dafür gibt es ja sinnvolle Anwendungsbeispiele.

kA.. also stimmst du mir zu dass hier lediglich ein Deadlock gezeigt wird, aber kein sinnvoller Code der jetzt irgendwie synchronisiert werden muss geschweige denn das tut, was Sun darüber aussagt? Finde das halt schon ein sehr madiges Beispiel dann..

Ist ja wie wenn ich jemandem den Sinn von nem Setter erklären will und sage: "Wenn die Variable private ist". Aber es geht ja darum warum die Variable überhaupt private ist. Genauso finde ich gehört zu nem Deadlock Bsp ein Anwendungsfall in dem man synchronisiert weil man sonst Race Conditions kriegt... Einfach nur paar Keywords zusammenklatschen ist ja wohl keine tolle Erklärung.

 

[hdi]

edit: Ach alles quatsch, also ich check das Bsp echt nicht -.- Das synchen macht einfach null Sinn iwie..

 

[MQue]

Also das synchronized macht ja erst den Deadlock, das Problem ist, dass beide Threads gleichzeitig starten und dann die Threads auf den anderen Thread warten, bis der was macht, ein klassischer Deadlock halt.
Probiers mal so, vielleicht hilfts fürs Verständnis(wenn du die Threads hintereinander startest, dann geht sichs aus, dass der eine schon fertig ist bevor der andere startet -> daher sind Deadlocks auch so schwierig zu finden)

public static void main(String[] args) {
            final Friend alphonse = new Friend("Alphonse");
            final Friend gaston = new Friend("Gaston");
            new Thread(new Runnable() {
                public void run() { 
                    alphonse.bow(gaston);
                    }
                }).start();
            try {
                Thread.sleep(2000);
                }
            catch(Exception e) {
                System.out.println("Ausnahme: " + e);
                }
            new Thread(new Runnable() {
                public void run() { 
                    gaston.bow(alphonse);
                    }
                }).start();
            }

Auch beim nächsten sind die Threads unabhängig (d.h. der eine Thread muss nicht auf den anderen warten) und alles funkt:

public static void main(String[] args) {
            final Friend alphonse = new Friend("Alphonse");
            final Friend gaston = new Friend("Gaston");
            new Thread(new Runnable() {
                public void run() { 
                    alphonse.bow(alphonse);
                    }
                }).start();
            new Thread(new Runnable() {
                public void run() { 
                    gaston.bow(gaston);
                    }
                }).start();
            }

 

[hdi]

Ich glaub wir reden etwas aneinander vorbei. Mir ist schon klar was ein Deadlock ist und wie er entsteht. Es geht mir darum dass ich ein gutes Beispiel aus der Praxis suche in dem Deadlocks auftreten können. Vorbedingung ist dann also dass man etwas synchronisiert. Und dass in dem Bsp von Sun synched wird verstehe ich eben nicht - ich finde das Programm tut nicht das, was Sun sagt und muss nicht synchronisiert werden bzw. der Deadlock ist total künstlich herbeigeführt. Lass doch mal das synchronized bei den Methoden weg.. Dadurch ändert sich die Programmlogik gar nicht.

 

[MQue]

Lass doch mal das synchronized bei den Methoden weg.. Dadurch ändert sich die Programmlogik gar nicht.

Aber die Ausgabe auf der Konsole ist eine andere.
Schau dir mal das an, dass sind konkrete Beispiele (Java Concurrency in Practice) -> Kapitel 2.7, 8.1 usw.

 

[Firestorm87]

Es geht mir darum dass ich ein gutes Beispiel aus der Praxis suche in dem Deadlocks auftreten können.

In der Praxis treten solche Deadlocks prinzipiell eher in längeren Threads auf.
Es ist ja durchaus möglich, dass solch eine Aktion nicht nur wenige millisekunden dauert, sondern vielleicht sogar mehrere Stunden.
Und um dann die gesamtgeschwindigkeit zu erhöhen Verarbeitet man mehrere Sachen parallel, die auch abhängigkeiten zueinander haben.

Und hier sollte einem ohne Probleme einleuchten, dass die wahrscheinlichkeit, dass es hier zu kollisionen kommen kann wesentlich realistischer ist, als bei 2-3 millis

Zumal solche deadlocks mir bisher eher im Datenbankbereich (das managed die dann selber) oder bei den Schreibzugriffe auf Datein untergekommen sind, da zentrale Daten eben oftmals von mehreren Abläufen benötigt werden.

/EDIT: Was aber nicht heißt, dass man bei solchen Fälle wie in den Beispielen drauf verzichten kann/darf, weil das eh nicht passiert !!!!!!! Gerade an solchen Fällen kann man sehen wie "schnell" sowas gehen kann..... also lieber einmal zu vorsichtig, als einmal zu nachsichtig!

 

[Janus]

Das Beispiel macht genau das, was Sun sagt und auch nur genau deshalb, weil die Methoden synchronized sind.

Jemand soll sich verbeugen, bis der andere sich ebenfalls verbeugt hat. Jeder Verbeuger kann sich zu jedem Zeitpunkt nur gerade genau einmal verbeugen, oder genau einmal zurückverbeugen. Um dies zu bewerkstelligen, wird synchronized verwendet. Das Beispiel ist meiner Meinung nach exzellent.

 

[FArt]

Du willst ein einfaches Beispiel, aber es soll nicht so künstlich sein... schwer.
Das Beispiel ist sinnvoll, das Verbeugen soll eine atomare Aktion sein, deswegen ist sie synchronisiert, und das steht in der Beschreibung. Verbeugen und Zurückverbeugen sind untersschiedliche Aktionen und somit zählt A verbeugt sich und B verbeugt sich... nicht.
Das Beispiel ist ähnlich zu den Philosophen, aber noch mal ein wenig künstlicher...

 

[Marco13]

Man könnte jetzt versuchen, ein anderes Beispiel zu konstruieren, was mehr oder weniger eine "Umbenennung" des obigen Beispiels ist. Etwa sowas wie: Es gibt Klassen, die Nachrichten austauschen. Ein Sender schickt eine Nachricht an den Receiver. Wenn ein Receiver eine Nachricht erhält, schickt er eine Empfangsbestätigung an den Sender, der daraufhin die Nachricht aus seinem Speicher löschen kann.

class Sender
{
    private List<String> messages = new ArrayList<String>();
    
    // Muss synchronized sein, damit nicht Thread B das
    // Erstellen einer neuen Nachricht veranlasst, bevor
    // Thread A seine vorher gebaute Nachricht an den
    // Receiver geschickt hat
    public synchronized void sendMessageTo(Receiver receiver)
    {
        String message = buildMessage();
        messages.add(message);
        receiver.receiveMessage(this, messages.get(messages.size()-1));
    }

    // Muss synchronized sein, damit es nicht zwischen den 
    // obigen Zeilen mit 'messages.add' und 'reveicer.receiveMessage'
    // aufgerufen werden kann
    public synchronized void discardMessage(String message)
    {
        messages.remove(message);
    }
}


class Receiver
{
    private String lastMessage;

    // Muss synchronized sein, damit nicht zwischen den
    // beiden Zeilen ein anderer Thread die Methode aufruft
    public synchronized void receiveMessage(Sender sender, String message)
    {
        lastMessage = message;
        sender.discardMessage(lastMessage);
    }

}

Da müßte es auch einen Deadlock geben können... ? (Müßte man aber nochmal genauer verifizieren, so früh am Morgen und mit so einem niedrigen Koffeinspiegel will ich da mal keine Garantien geben )

Ist halt AUCH konstruiert, aber zumindest habe ich versucht, die synchronizations zu rechtfertigen... Vielleicht wird wenigestens die Grundidee deutlich....

 

[JanHH]

Naja, Abstürze und Fehler treten ja nunmal wegen Programmierfehlern auf, die KEINEN Sinn machen. Sicher sind die synchronizeds bei solchen Beispielen falsch und unsinnig. Aber da falsches und unsinniges Programmieren nunmal die Ursache von Fehlern ist, sind auch solche Beispiele legitim und sinnvoll.