Multithreading, Methoden sichern

[Coolies]

Hi,
ich habe mir ein Programm zusammengebastelt, dass aus mehreren Threads besteht und die gleichzeitig auf eine Methode zugreifen können.
Mein problem besteht nun darin, das der eine Thread "Paul" auf diese Methode zugreift und ein weitere Thread "Hans" dies ebenfalls tun will.
So wenn Hans und Paul dies gleichzeitig tun, dann stürtzt mir das Programm ab (nicht immer aber es kann durchaus passieren). Um das Problem zu lösen hab ich mich ein wenig belsen, hab aber nicht verstanden was ich alles brauche...
ich hab herausgefunden, dass ich meine Methoden mit

private final Lock nichtSchreiben	= lock.writeLock();
private final Lock nichtLesen		= lock.readLock();

public void Methode() {
	  nichtSchreiben.lock();
	  try {
		 //Hier darf nur ein Thread gleichzeitig zugreifen
	  } finally {
		  nichtSchreiben.unlock();
	  }
}

schützen kann, dass eben nur Hans oder Paul auf die Methode zugreifen kann und der andere wartet halt solange bis die Methode wieder frei ist... ist das so richtig?
Muss ich meine Varibalen zusätzlich mit dem Keyword "volatile" deklarieren?
Kann ich auf

.readLock()
.writeLock()

verzichten, wenn ich meine Methoden mit "synchronized" deklariere?
Muss ich alle veränderung innerhalb der Methode durchführen oder kann ich auch den Rückgabewert veränden? z.B. Mehtode2().verändereHierIrgendwas(); .
Gibt es vllt. noch andere (bessere) möglichkeiten mein problem zu lösen?

danke
Kevin

 

[Michael...]

verzichten, wenn ich meine Methoden mit "synchronized" deklariere?

Hab noch nie mit Locks gearbeitet. Wenn ich das richtig verstanden habe kann man mit Locks gezielt Code Abschnitte für den Zugriff durch andere Threads sperren.
Gleiches kann zwar mit synchronized, allerdings sind dann alle mit synchronized "markierten" Abschnitte für andere Threads gesperrt - was ja oft sinnvoll ist.
Ich würde also sagen, wenn Du überall das selbe Lock verwendest entspricht das der serlben Wirkung wie synchronized. Bei der Verwendung mehrerer Locks würde ich erstmal überprüfen, ob diese notwendig sind.

Muss ich alle veränderung innerhalb der Methode durchführen oder kann ich auch den Rückgabewert veränden? z.B. Mehtode2().verändereHierIrgendwas(); .
Gibt es vllt. noch andere (bessere) möglichkeiten mein problem zu lösen?

Das habe ich nicht verstanden. Eventuell beschreibst Du mal Dein konkretes Problem.

 

[Coolies]

ok danke für deine antwort
ich denke synchronized ist genau das was ich suche..

ich glaub nen beispiel sagt mehr als 1000 worte

private String test;
public synchronized String Method() {
	  return test;
}
public static void main(String args[]) {
          System.out.println(Method().length());
}

1. Thread ließt die die größe des String
2. Thread verändern den String

und das sollte ja jetzt nicht mehr möglich sein, dass der 1. und der 2. gleichzeitig auf die Methode zugreifen...
Was passiert eigentlich mit dem Thread der warten muss? Bleibt er einfach an der Programmstelle, bis er drauf zugreifen kann?

 

[Mindstream]

1. Thread ließt die die größe des String
2. Thread verändern den String

Strings kann man nicht verändern. Method().verändere() wird deshalb nicht so funktionieren wie du es dir vermutlich vorstellst. Und auch nicht MyClass.verändere(Method()) . Die Variable bleibt davon völlig unberührt.
Soweit ich dein Problem verstanden habe brauchst du eine Methode

public synchronized String Method(Boolean verändere) {
      if(verändere){
          test = test + " . " //verändere die globale variable
          return test;
      } else {
          return test;
      }

}

Damit kannst du sicherstellen, dass test entweder gelesen wird oder verändert wird. Unabhängig von der Anzahl der Threads die auf die Methode zugreifen.

Was passiert eigentlich mit dem Thread der warten muss? Bleibt er einfach an der Programmstelle, bis er drauf zugreifen kann?

Ja. Ich glaube er wartet auf ein Signal von einem anderen Thread, der aktiv ist. Eine andere Möglichkeit ist das busy waiting - dabei läuft er in einer Schleife und fragt periodisch ob er schon auf die gesperrte Resource zugreifen kann (vereinfacht dargestellt ist die Resource hier die Methode Method).

 

[Coolies]

Strings kann man nicht verändern. Method().verändere() wird deshalb nicht so funktionieren wie du es dir vermutlich vorstellst. Und auch nicht MyClass.verändere(Method()) . Die Variable bleibt davon völlig unberührt.

gut vllt. waren Strings nicht das beste beispiel, aber ich kann mir ja eine Klasse schreiben in der das möglich ist und die dann wiedergeben.

public synchronized irgendeineKlasse Method() {
      return test;
}

Ist das denn trotzdem Koscher

Ja. Ich glaube er wartet auf ein Signal von einem anderen Thread, der aktiv ist. Eine andere Möglichkeit ist das busy waiting - dabei läuft er in einer Schleife und fragt periodisch ob er schon auf die gesperrte Resource zugreifen kann (vereinfacht dargestellt ist die Resource hier die Methode Method).

gut dann muss ich das ja nicht explizit regeln

Weißt du was es mit dem keyword "volatile" auf sich hat? bzw. wann ich es verwende?

 

[Mindstream]

gut vllt. waren Strings nicht das beste beispiel, aber ich kann mir ja eine Klasse schreiben in der das möglich ist und die dann wiedergeben.

public synchronized irgendeineKlasse Method() {
      return test;
}

Ist das denn trotzdem Koscher

Thread 1 und 2 holen sich nacheinander irgendeineKlasse
Thread 1 und 2 greifen gleichzeitig auf irgendeineKlasse zu bzw verändern sie gleichzeitig.
-> nichts gewonnen
Was du in dem Fall am besten machen kannst ist zwei Methoden für IrgendeineKlasse zu definieren, die beide mit synchronized behaftet sind. Dann kannst du bedenkenlos:
irgendeineKlasse.verändere();
und
irgendeineKlasse.lese();
in beliebig vielen Threads aufrufen und es wird immer nacheineander geschehen.

gut dann muss ich das ja nicht explizit regeln

Weißt du was es mit dem keyword "volatile" auf sich hat? bzw. wann ich es verwende?

Hmm, ich glaube irgendeineKlasse als volatile zu definieren wäre auch eine Lösung. Jedoch werden dann alle Methoden und alle Zugriffe auf Variablen von irgendeineKlasse synchronisiert.