synchronized methode rekursiv aufrufen

[redbomber]

Hi zusammen,

eine kurze Verständisfrage. Wenn ich eine Methode synchronized mache, kann ich diese dann rekursiv aufrufen?

habe hierzu folgendes gefunden:

Da die Sperre während der gesamten Ausführung einer synchronized-Methode nicht mehr abgegeben wird, kann kein anderer Thread in dieser Zeit eine synchronized-Methode auf dem gesperrten Objekt ausführen. Dagegen kann der Thread, der das Sperrobjekt bereits besitzt, sehr wohl weitere geschützte Methoden aufrufen, weil Monitore in Java reentrant sind.

Das bedeutet dass der Thread auch rekursiv die Methode aufrufen kann.

Aber hier ist der Rat der folgende:

The simplest way to avoid deadlock is to follow the rule that says a synchronized method should never call a synchronized method.

Was also stimmt jetzt.
Vielleicht kann ich euch zeigen in welchem Fall ich meine Methode synchronized machen möchte:

class MyObject{
public synchronized void doCount(){
int count=0;
       for(int i = 0; i < getSubObjectsCount(); i++){
            MyObject object = getSubObject(i);
            count = count + object.doCount();
       }
return count;
}}

 

[eRaaaa]

Das erste ist korrekt, sind definitiv reentrant. Vllt. fehlt beim Zweiten einfach nur ein Wort?
"should never call another synchronized method" ?

 

[Murray]

Die zweite Regel ist sicher nicht falsch: wenn man so vorgeht, vermeidet man Deadlocks. Allerdings gilt der Umkehrschluss eben nicht: wenn man diese Regel nicht beachtet, muss das nicht unbedingt ein Deadlock-Risiko bedeutet.
Was man vermeiden muss, ist aus einem Kontext, der auf einen bestimmten Monitor synchronisiert, in einen anderen Kontext zu springen, der auf einen anderen Monitor synchronisiert. Falls man das nämlich täte und ein anderer Thread das ebenfalls, aber in der umgekehrten Reihenfolge machte, dann würde man evtl. einen Deadlock verursachen.
Ruft man aus einer als synchronized deklarierten Methode diese Methode (oder eine andere, in der gleichen Klasse ebenfalls als synchronized deklarierte Methode) auf, so ist der Monitor ja immer die aktuelle Instanz (und damit bei beiden Aufrufen derselbe).

 

[vavav]

Die Methode hat den lock und der erneute Eintritt geht schnell und problemlos. Daran ist also nichts falsch.

 

[redbomber]

ok vielen Dank!
Ich weiss jetzt also was korrekt ist und in welchem Fall ein solcher Deadlock eintreten kann.

 

[LeJOS for Lego]

Ich habe eine kleine Frage, die sehr ähnlich gelagert ist wie oben, aber dennoch etwas anders.

Ich habe eine synchronisierte Methode, die der Übersichtlichkeit halber, rekursiv sein sollte. Hier der Codeschnipsel:

// Im Methodenkopf sind folgende Konstanten definiert:
public static final int U_TURN = -200;
public static final int NORMAL = -300;
public static final int INITIAL = -400;

// Diese Methode meine ich:
	/**
	 * Versucht den nächsten Knoten und die nächste Kante zu sperren.
	 * 
	 * @param start: nächster Knoten
	 * @param end: übernächster Knoten
	 * @param method: Methode, die bestimmt, welcher Case ausgeführt wird.
	 * @return Status, ob das Sperren erfolgreich war.
	 *   1: Alles OK
	 *  -1: Kante gesperrt
	 *  -2: Knoten (und Kante) gesperrt 
	 */
	public synchronized int lockNextSegment(int start, int end, int method) {
		int i = 1; // Nicht spezifiziert
		int edge = edges[start][end].lockStatus();
		switch (method) {

			case INITIAL:
				edges[start][end].lock(CUEdge.LOCK);
				edges[end][start].lock(CUEdge.BLOCK);
				break;

			case U_TURN:
				releaseEdge(end, start);
				i = this.lockNextSegment(start, end, NORMAL);   // <-- Um diesen Aufruf geht es
				break;
	
			case NORMAL:
				/*
				  Das, was in diesem Case passiert, eine ordentliche if-else if-else-Schachtel,
				  die viel zu viel Code enthält, ist für die Frage irrelevant,
				  es werden diverse Stati überprüft und ggf. eine Kante und ein
				  Knoten in einem Graphen gesperrt, bzw. der Status der Aktion
				  in i gespeichert.
				*/
				break;

		}
		updateStreetMap();
		return i;
	}

Ist das so valide oder muss ich irgendetwas anders machen? Falls ja, was?