Wie erschaffe ich einen sicheren Datenaustausch zwischen Thread und Nicht-Threads

[JeromeC]

Hallo liebe Inselbewohner,

ich überlege den ganzen morgen, wie ich einen Thread erstelle und mit ihm aus anderen Klassen agiere.
Das knifflige: Der Thread muss noch einmal die Stunde eine interne Methode ausführen.

Könnt ihr mir bitte auf die Sprünge helfen? Komm gerade auf keine saubere Lösung.
Ich scheitere daran, dass ich den Thread gerne stoppen würde, wenn die interne Methode ausgeführt wird, damit die Daten konsistent bleiben. Wenn ich das so machen würde, was würde mit eintreffenden Methodenaufrufen passieren (die von außen)?

Grüße, jC

 

[Thallius]

Zunächst mal verstehe ich nicht ewas für Dich Nicht-Threads sind? Jeder Programmcode der abgearbeitet wird läuft in einem oder mehreren Threads. Es gibt keine Nicht-Threads.

Dann verstehe ich nicht was für Dich eine interne Methode ist? Ich kenne private, public etc aber intern ist mir neu....

Wie können von aussen Methoden aufgerufen werden und vor allem von wem warum weswegen auch immer?

confused

Claus

 

[JeromeC]

Ja, eine private Methode, was sonst.
Ich möchte aus einem POJO auf den Thread zugreifen.
Beispiel in vereinfachter Form, ohne Anspruch auf Richtigkeit, nur für Anschauungszwecke zu nutzen:
[Java]
public class LoginInformationManager extends Thread {

private final List<String> keyList = new ArrayList<String>();

public void run() {
//Wenn eine Stunde vorbei, führe checkKeyList() aus
}

private void checkKeyList() {
for(String key : keyList) {
if(key.equals("Irgendwas") {
keyList.set(keyList.indexOf(key), "foobar");
}
}
}

public void setNewKey(String key) {
keyList .add(key);
}

public String getKey(int index) {
return keyList.get(index);
}

}
[/Java]

Entschuldige die unpräzise Frage.
Die Frage ist, ob die zeitliche Steuerung der Klasse LoginInformationManager (sprich die Ausführung der Methode 'checkKeyList') von der Klasse selbst durchgeführt wird oder an der Stelle, wo die Klasse instanziiert wird.
Um es nochmal in Anderen Worten auszudrücken:
Die Liste soll jede Stunde überprüft werden. Da aber die Klasse GLEICHZEITIG von Pojos aufgerufen wird (Methode 'setNewKey' oder 'getKey'), frage ich mich, wie ich das alles kombiniere, ohne dass die Elemente der Liste durcheinander geraten / es zu Fehlern kommt, z.B. durch ArrayOfOutBound.
Ich hoffe, ich habe es diesmal verständlicher ausgedrückt.

Grüße, jC

P.S.: Die zeitliche Perspektive ist wichtig, da es sich insgesamt um ein Webprojekt handelt. Daten aus der Thread-Klasse können also vielmals und zu jederzeit abgerufen werden. Der Thread soll nach dem deployen des Webprojekts zum Leben erwachen und ab da an jede Stunde diese Prüfung der Liste durchführen.

 

[Joose]

Ich möchte aus einem POJO auf den Thread zugreifen.

Ein POJO sollte eigentlich nur eine simple Klasse sein mit gettern/settern ohne nennenswerter Logik (also nicht irgendwo Daten hinzufügen).
Aber das nur nebenbei.

Die Frage ist, ob die zeitliche Steuerung der Klasse LoginInformationManager (sprich die Ausführung der Methode 'checkKeyList') von der Klasse selbst durchgeführt wird oder an der Stelle, wo die Klasse instanziiert wird.

Du könntest mit "synchronized" Blöcken arbeiten.
In "setNewKey", "getNewKey" bzw. "checkKeyList" jaweils einen "synchronized" Block der Liste als Objekt.
Dadurch kann immer nur ein POJO zur gleichen Zeit etwas hinzufügen/rausholen. Bzw. wenn der Thread die Liste checkt, kann kein POJO etwas hinzufügen.

 

[JeromeC]

Ich halte die Wiki-Definition eigentlich für ganz passend für den Begriff 'POJO', zumindestens habe ich diese immer in dem Zusammenhang genutzt:

Ein POJO ist ein Java-Objekt, das keinerlei Einschränkungen bis auf die der Java Language Specification hat.

Aber es geht mir einfach darum, dass die public-Methoden nicht von der Klasse 'LoginInformationManager' genutzt werden, die Verwaltung der Liste aber möglichst innerhalb der Klasse stattfinden soll und keine Konflikte auftreten sollen zwischen den beiden Vorgängen. Ich habe gelesen, dass das inkrementieren von Variablen in Java Thread-safe ist, ich wüsste aber nicht ob das auch auf die Methoden von List zutrifft.

Danke für den Hinweis Joose, ich werde mich in die Thematik einlesen.

 

[Joose]

Ich halte die Wiki-Definition eigentlich für ganz passend für den Begriff 'POJO', zumindestens habe ich diese immer in dem Zusammenhang genutzt:

Gut da gehen Meinungen auseinander

Aber es geht mir einfach darum, dass die public-Methoden nicht von der Klasse 'LoginInformationManager' genutzt werden, die Verwaltung der Liste aber möglichst innerhalb der Klasse stattfinden soll und keine Konflikte auftreten sollen zwischen den beiden Vorgängen.

Wie oben schon erwähnt -> "synchronized" Blöcke verwenden

Ich habe gelesen, dass das inkrementieren von Variablen in Java Thread-safe ist, ich wüsste aber nicht ob das auch auf die Methoden von List zutrifft.

Variablen inkrementieren in Java ist nicht ThreadSafe ... AtomicInteger ist eine spezielle Klasse, schau dir mal den Aufbau dieser Klasse an

 

[JeromeC]

Variablen inkrementieren in Java ist nicht ThreadSafe ... AtomicInteger ist eine spezielle Klasse, schau dir mal den Aufbau dieser Klasse an

Ja da hast du recht, hatte den Artikel nur überflogen

Ich habe jetzt die Methoden mit 'synchronized' versehen und nutze die Klasse 'Timer' um meine Prozesse zur richtigen Zeit zu starten. Also vielen Dank für die hilfreichen Tipps.

Bei meinen Tests kam es auch zu keinen Zugriffsfehlern. Aber nur noch einmal zur Sicherheit:
Eine mit 'synchronized' versehene Methode arbeitet parallele Zugriffe sequentiell ab, mit einer Art Warteschlange nehme ich an. Aber was passiert, wenn ich z.B. eine synchronized read und eine synchronized write Methode habe und beide zur selben Zeit von 2 Threads aufgerufen wird? Kann es passieren, dass Probleme auftreten oder kümmert sich 'synchronized' auch um die Ressource / Variable, auf die zugegriffen wird?

 

[arilou]

Die Warteschlange eines 'synchronized' ist Attribut des Objekts, zu dem die Methode gehört (bei static-Methoden das zugehörige .class-Objekt). Hat ein Thread A es geschafft, in eine synchronized-Methode zu gelangen (oder einen synch.-Abschnitt), so werden alle anderen synchronized-Abschnitte/Methoden (dieses Objekts) geblockt (entsprechende Zugriffe in die Warteschlange gestellt), bis der Thread A den synch.-Abschnitt wieder verlassen hat.

Thread A selbst darf derweilen jedoch unbekümmert weitere synchronized-Methoden (des aktuellen Objekts) aufrufen (er kann sich also nicht "selber blocken"). Erst wenn er "aus allen wieder heraus ist", geht's für die anderen weiter (oder zumindest einen davon).

 

[arilou]

Thread A sollte innerhalb eines synch.-Abschnitts aber nicht auf synch.-Methoden anderer Objekte zugreifen - dann kann es theoretisch zu einem Deadlock kommen.

Merke: Synch.-Abschnitte so kurz wie möglich, bei so wenig Methoden wie möglich, und darin möglichst nicht zugreifen auf synch.-Abschnitte/Methoden anderer Objekte.