Frage Threads

[DaSt]

Hallo,

in unserem Skript steht ein Bsp.

"
Sehen Sie sich folgende Überweisung von Konto k1 auf Konto k2 an.
Hier gibt es Probleme mit gegenseitigem Warten/Verklemmung!
Wieso? Unter welchen Umständen?
"

public synchronized void überweisen(Konto k1,Konto k2,int betrag){
 
        synchronized(k1){
              synchronized(k2){
                    k1.kontostand-‐= betrag;
                      k2.kontostand+=betrag;
               }
      }
}

Kann mir wer sagen, wo es hier zum Problem kommt?

Danke

 

[dennisbauer]

Wenn ich mir einen synchronized-Block anschaue, dann halte ich mir das etwas vereinfacht vor Augen, dass nur ein einziger Zugriff gleichzeitig auf den jeweiligen synchronized-Block passieren kann.

Grundlegend können hier keine Ressourcen innerhalb der Methode blockiert werden, da ja in der Methode, die synchronized ist, sich nur ein Aktionsträger befinden kann. Die Frage muss hier also dementsprechend sein, was passiert mit diesen Objektinstanzen k1 und k2 außerhalb der Methode?

Warten müssen die Aktionsträger hier, sobald Konto k1 oder Konto k2 auf ein anderes Konto überweisen möchten. Dann ist diese Ressource belegt und es wird auf die Freigabe in den jeweiligen Synchronized-Blöcken gewartet.

Gleiches gilt, wenn eines der beiden Konten eine Überweisung eines anderen, dritten Kontos erhält.

Die eigentliche Verklemmung, die hier stattfinden kann ist, wenn gleichzeitig Konto1 eine Überweisung an Konto2 durchführen möchte, Konto2 jedoch gleichzeitig eine Überweisung an Konto1. Dann sind im ersten Synchronized-Block alle beiden Ressourcen belegt und am zweiten Synchronized-Block wird auf die jeweils andere Ressource gewartet, bis diese freigegeben wird, was jedoch nie passieren wird, da diese Freigabe die Freigabe der anderen Ressource erfordert.

 

[DaSt]

danke

 

[mrBrown]

Die eigentliche Verklemmung, die hier stattfinden kann ist, wenn gleichzeitig Konto1 eine Überweisung an Konto2 durchführen möchte, Konto2 jedoch gleichzeitig eine Überweisung an Konto1. Dann sind im ersten Synchronized-Block alle beiden Ressourcen belegt und am zweiten Synchronized-Block wird auf die jeweils andere Ressource gewartet, bis diese freigegeben wird, was jedoch nie passieren wird, da diese Freigabe die Freigabe der anderen Ressource erfordert.

Es gibt nicht nur 2, sondern 3 synchronized-Blöcke, die Methode selbst ist schon synchronized - vorausgesetzt, jede Überweisung läuft über das gleiche Objekt, können beide Überweisungen nur nacheinander ausgeführt werden. Erst wenn die Überweisung k1->k2 abgeschlossen ist, kann die Überweisung k2-k1 gestartet werden, und die Verklemmung ist ausgeschlossen.

 

[DaSt]

Hätte noch eine Frage: folgender Code + Fragen gegeben

public class P{

   private int count =0;

   public void add(){
         synchronized(???){
              this.count++;
         }
   }
}

Welche Auswirkungen hat es wenn die ??? durch folgende Ausdrücke ersetzt werden:

a) this -> Das funktioniert
b) m und nach int count: Object m = new Object(); -> das sollte ebenfalls funktionieren
c)P.class oder this.getClass() -> hier bin ich mir nicht sicher
d)"IrgendeinString" -> Wird kompeliert (da Strings ja Objekte sind), aber welche konkrete Auswirkung das hat weiss ich nicht
e) new Object() -> wird kompeliert aber bin mir nicht sicher ob es auch wirklich sperrt, da ja jedesmal ein neues Object erstellt wird

 

[dennisbauer]

@mrBrown Ich sehe das nur als 2 synchronized-Blöcke an plus die synchronized Methode, welche ich aber eher ausgeblendet habe, da sie zwar grundsätzlich auch von Verklemmung betroffen sein kann, in diesem Beispiel aber eher weniger von Belang ist.

@DaSt
c: Als Rückgabe-Parameter erhälst du ein Class-Objekt, welches im Grunde auch von Object abgeleitet ist. Ich verstehe deine Ausführung in e) dann nur nicht. Sperren tut dir das synchronized den Zugriff auf das Objekt, bis es wieder released ist. Da new Objekt immer wieder ein Objekt mit neuer Signatur erstellt, gibt es an dieser Stelle keinen konkreten Fall, an dem irgendein anderer Aktivitätsträger blockiert wird, da die Resource auf die zugegriffen wird, ja immer neu erstellt wird.
Anderer Fall ist hier in der Tat c). Meines Wissens nach werden Class-Objekt-Instanzen nur einmal zur Laufzeit generiert (simpel ausgedrückt, tatsächlich steckt mehr dahinter und kann auch durchaus abhängig von der Anzahl an verschiedenen Classloadern sein). Diese Class-Objekte sind während der Laufzeit stets identifizierbar, besitzen die gleiche Signatur. Dementsprechend sollte an dieser Stelle im synchronized-Block eine Sperre erfolgen, da auf die gleiche Klasse zugegriffen wird.

d) Strings sind ebenfalls lediglich weitere Implementierungen vom Typ "Object", dementsprechend zu behandeln wie oben genannt. Das String-Objekt wird bei jedem Aufruf der Methode neu instanziiert, dementsprechend neue Signatur -> keine Sperre

e) bereits genannt

 

[mrBrown]

Ich sehe das nur als 2 synchronized-Blöcke an plus die synchronized Methode, welche ich aber eher ausgeblendet habe, da sie zwar grundsätzlich auch von Verklemmung betroffen sein kann, in diesem Beispiel aber eher weniger von Belang ist.

Der dritte Block spielt halt schon eine Rolle - eben da er eine Verklemmung verhindert, wenn es das entsprechende Objekt nur einmal gibt ^^

Strings sind ebenfalls lediglich weitere Implementierungen vom Typ "Object", dementsprechend zu behandeln wie oben genannt. Das String-Objekt wird bei jedem Aufruf der Methode neu instanziiert, dementsprechend neue Signatur -> keine Sperre

Der erste Satz stimmt - der zweite nicht mehr. An der Stelle gibt es

Ich verstehe deine Ausführung in e) dann nur nicht. Sperren tut dir das synchronized den Zugriff auf das Objekt, bis es wieder released ist. Da new Objekt immer wieder ein Objekt mit neuer Signatur erstellt, gibt es an dieser Stelle keinen konkreten Fall, an dem irgendein anderer Aktivitätsträger blockiert wird, da die Resource auf die zugegriffen wird, ja immer neu erstellt wird.

Effektive ist das genau das was er sagt, es gibt keine Sperre, die irgendwas bewirkt. Ich bin mir nicht sicher was der JIT draus macht, aber theoretisch kann das synchronized einfach wegoptimiert werden.