Alternative für Threads

[Wippi11223]

Hallo,

Ich habe folgende Anforderung an mein System und bin auf der Suche nach einer alternativen Lösung als Threads oder eine Verbesserung mit Threads:

Meine Applikation führt kontinuierlich Berechnungen durch Berechnung A --> ab einen gewissen Zeitpunkt initiiere ich einen Thread und führe eine parallele Berechnung durch Berechnung B1, B2, B3 --> wenn der Thread beendet ist aktualisiert dieser eine Hashmap in der Hauptapplikation. Dies ist natürlich gefährlich denn es passiert manchmal dass ich gerade in selben Moment in der Hauptapplikation durch die Hasmap iteriere während mir gerade ein Thread die Hashmap aktualisiert und das führt dann zu Problemen.

Alternative Architektur
Habt ihr einen Vorschlag für ein besseres Design, Architektur bzw. Lib wie ich das lösen kann?
Ich benötige etwas wo ich eine Berechnung "hinschicken" kann --> wenn sie fertig ist soll sie sich wieder melden damit ich diese verarbeiten kann --> während dessen soll die Applikation aber weiter rechnen.

Verbesserte Architektur mit Threads
Derzeit starte ich den Thread aus der Hauptapplikation --> wenn sie fertig ist dann ruft der Thread eine statische Methode in der Hauptapplikation auf um die Hashmap zu aktualisieren --> ich finde diese Lösung nicht besonders toll -> gibt es eine Alternative dafür ohne dass ich hier eine statische Methode aufrufen muss?

Ich hoffe ihr könnt mir hier weiterhelfen.


Vielen Dank

 

[White_Fox]

Guckste hier:

Locks in Java

This tutorial explains what a lock is in multithreading, shows an example of how to implement a lock, and discusses topics like reentrance, and when to unlock a lock etc.

tutorials.jenkov.com

 

[Wippi11223]

ok danke bin mir nicht sicher ob das das problem löst habe aber hier gelesen dass ich auch ein anderes Problem habe ich verwende Hashmaps und so weit ich gelesen habe sollte man diese in Verbindung mit Threads nicht verwenden oder?

Openbooks. Rheinwerk-Bücher kostenlos online lesen. Ein Service des Rheinwerk Verlags

openbook.rheinwerk-verlag.de

nicht thread-sicher	Thread-sicher
StringBuilder	StringBuffer
ArrayList	Vector
HashMap	Hashtable

 

[LimDul]

Sobald du mehr als einen Thread hast, musst du dich drum kümmern, dass die sauber auf gemeinsamen Daten arbeiten. Das heißt, du musst sicherstellen, dass es bei Verändern von gemeinsamen Daten keine Probleme gibt.

Bzgl. der Collections API gibt es nicht Thread Safe Klasse. Das heißt, wenn du die verwendest, musst du sicherstellen (siehe Beitrag von @White_Fox) das nie zwei Threads gleichzeitig auf der Struktur hantieren.

Nutzt du die Thread-sicheren klassen, dürfen grundsätzlich auch zwei Threads gleichzeitig drauf hantieren. Aber nur aus technischer Sicht. Fachlich muss man das immer noch prüfen und alles geht gleichzeitig nicht. So wirst du mit Sicherheit auch bein Thread-sicheren Klassen nicht in dem einen Thread drüber iterieren können und in dem anderen die Collection ändern. Weil das steht bei HashTable in der Javadoc:

If the map is modified while an iteration over the set is in progress (except through the iterator's own remove operation), the results of the iteration are undefined.

Sprich, das musst du trotzdem sicherstellen, dass das nicht passiert.

Multi-Threading kann leider schnell sehr häßlich werden.

 

[Wippi11223]

@Multithreads
Ja ich denke auch das Mutli Threading nicht das beste ist - gibt es nicht LIBs die solche Anforderungen abdecken - eigentlich brauche ich ein Queuing System in den ich nach Berechnung notifiziert werde und dass es manuell verarbeitet - lässt sich soetwas nicht mit Observables lösen?

@Architektur
Das heisst ich muss dies wie folgt lösen:
Hauptapplikation A berechnet ( diese Klasse inkludiert die Hashmap und eine statische Methode in der ich die Hashmap aktualisiere)
--> Thread A startet
--> Thread B startet
--> Thread A ist fertig und nun möchte ich die statische Methode aufrufen um die Hashmap zu aktualisieren --> das bedeutet diesen Aufruf muss ich unter Lock stellen oder? Gibt es eine Möglichkeit die statische Methode wegzubekommen?

==> das löst zwar das Problem dass nicht 2 Threads gleichzeitig auf die Hashmap zugreifen - aber es löst nicht das Problem dass während dessen die Hauptapplikation über die Hashmap iteriert richtig? Gibt es eigentlich eine Lösung dafür? Denn das kann ich ja nicht sicherstellen dass dies nicht gleichzeitig passiert....

 

[White_Fox]

Die Frage ist (aus meiner Sicht), warum müssen es mehrere Threads sein. Dauert die Berechnung sonst zu lange?

==> das löst zwar das Problem dass nicht 2 Threads gleichzeitig auf die Hashmap zugreifen - aber es löst nicht das Problem dass während dessen die Hauptapplikation über die Hashmap iteriert richtig? Gibt es eigentlich eine Lösung dafür? Denn das kann ich ja nicht sicherstellen dass dies nicht gleichzeitig passiert....

Das kommt darauf an wie du das implementierst, du hast ja insgesamt drei Threads: Thread A, Thread B und deine Hauptapplikation läuft in einem eigenen Thread. Aus Sicht eines threadsicheren Objekts ist es völlig egal, welcher Thread da zugreift, es stellt sich gefälligst jeder hinten an.
Wenn aber deine Hauptapplikation am Threadlock vorbei auf die HashMap zugreifen kann ist das natürlich Mist. Wenn aber auch deine Hauptapplikation über die gleichen Methoden auf der HashMap rumwerkelt sollte das kein Problem sein.

Ich würde die Datenstruktur, sofern du die HashMap verwenden willst/mußt, in einer separaten Klasse kapseln, sodaß nur über von mir definierte Methoden geschrieben und gelesen werden kann. Und innerhalb der Zugriffsmethoden würde ich die Zugriffsberechtigung regeln.

 

[mrBrown]

das bedeutet diesen Aufruf muss ich unter Lock stellen oder?

Nicht diesen, sondern alle Nutzungen der Map

Gibt es eine Möglichkeit die statische Methode wegzubekommen?

Das static weglassen

Einfach eine Referenz auf die entsprechende Klasse halten und diese nutzen.

==> das löst zwar das Problem dass nicht 2 Threads gleichzeitig auf die Hashmap zugreifen - aber es löst nicht das Problem dass während dessen die Hauptapplikation über die Hashmap iteriert richtig? Gibt es eigentlich eine Lösung dafür? Denn das kann ich ja nicht sicherstellen dass dies nicht gleichzeitig passiert....

Du musst einfach jede Nutzung absichern - wenn ein Thread die Map lesend benutzt, darf kein anderer Schreiben.


uU gibt es aber bessere Möglichkeiten, als eine HashMap dafür zu nutzen, vor allem wenn man regelmäßig über diese Iterieren muss. Queue hast du ja selbst schon genannt, ob und wie die nutzbar ist hängt natürlich vom genauen Anwendungsfall ab.