TThread, TTask usw. oder OmniThreadLibrary?

[Glados]

Durch das Forum lese ich zum ersten Mal vom OmniThreadLibrary-Projekt.

Die Library scheint ja sehr mächtig zu sein. Aber was genau macht sie besser als beispielsweise TParallel.For, TTask und TThread?
Ist die Implementierung in ein Projekt, welches oben genannte Strukturen verwendet, sorgenfrei oder verliere ich dabei meine grauen Haare?

[Redeemer]

Ich werfe an dieser Stelle auch noch den TIdThread in den Raum, den ich öfter verwende. Warum weiß ich auch nicht mehr, die Entscheidung ist 9 Jahre her. Da fiele mir ein Nachteil ein, dass ich den an sich nur synchronisieren, aber nicht queuen kann, da der zugrundeliegende TThread nicht sichtbar ist. Ich habe ihn mir daher so abgeleitet, dass der TThread sichtbar ist.

[Uwe Raabe]

Zitat:

Zitat von Glados (Beitrag 1383658)

Aber was genau macht sie besser als beispielsweise TParallel.For, TTask und TThread?

Der Funktionsumfang und die Möglichkeiten sind sicher deutlich besser. Allerdings funktioniert sie (bislang) nur für Windows/VCL. Dank des hervorragenden Buchs zu dieser Library ist die Dokumentation auch deutlich umfangreicher.

Für einfache Sachen nehme ich meist die PPL, weil - ist eben immer da. Für komplexe Dinge kommt dann die OTL ins Spiel, aber das bedeutet ja auch eine zusätzliche Abhängigkeit von einer externen Library bei der Versionsverwaltung.

Zitat:

Zitat von Glados (Beitrag 1383658)

Ist die Implementierung in ein Projekt, welches oben genannte Strukturen verwendet, sorgenfrei oder verliere ich dabei meine grauen Haare?

Die verliert man bei der Arbeit mit Multi-Threading doch sowieso. Da bin ich selbst das beste Beispiel :-D

[Glados]

Genau wegen des Multithreading habe ich gerade nämlich Probleme. Daher dachte ich OTL kann mir helfen?

- Button-Klick
-- repeat-Schleife 0 bis ListView-Items-Select-Count
--- Mache XY mit Daten Listview-Eintrag-N
---- Erstelle Threads (mehrere) für Arbeit XY
---- solange XY läuft, warte mit einer while-Schleife (!)
---- Wenn XY fertig, führe ein paar Prozeduren aus, um aufzuräumen
-- Arbeit fertig, zurück in repeat-until
- gehe wieder nach oben und fange erneut an

Nachdem ich alle Threads erstellt habe, muss ich ja irgendwie auf deren Beendigung warten und lauschen. Das mache ich aktuell mit einer while-Schleife.
Ich inkrementiere eine Variable bei jedem Erzeugen eines Threads. Wenn ein Thread sich beendet, wird diese Variable dekrementiert.
Die while-Schleife lauscht nun, bis die Variable = 0 ist. Erst dann werden weitere Prozeduren zum Aufräumen gestartet. Sind die durch, fängt der Spaß erneut an.

Kann ich hier nicht mit Messages arbeiten, damit zumindest schon einmal die while-Schleife wegbekomme?
Ich bin aktuell in der Lage zu sehen, welcher Thread der letzte Thread ist. Der könnte doch eine Message irgendwohin schicken?
Nur wie warte ich dann in der repeat-until-Schleife?

[TiGü]

Warte doch gar nicht, sondern lass dich vom fertigen Thread benachrichtigen!

Beschäftige dich mal hiermit:
http://docwiki.embarcadero.com/Libra...ad.OnTerminate

[Uwe Raabe]

Ohne das Problem auch nur ansatzweise analysiert zu haben, fällt mir hier der

Delphi-Quellcode:

TOmniEventMonitor

ein, eine Komponente auf deinem Form/Datenmodul die event-gesteuert dies erledigen könnte. Aber wie immer bei solchen Problemen ist eine pauschale Aussage nicht wirklich sinnvoll. Dazu müsste man den Anwendungsfall schon im Detail kennen.

[Sherlock]

Ich würde erstmal mit den Bordmitteln anfangen, und deren Grenzen ausloten. Wenn alles geht ist gut, falls das nicht ausreicht, weiter zu den Kanonen. Ich finde die PPL schon sehr gut.

Sherlock

[Glados]

Ein Problem gibt es aktuell keins. Während Arbeit XY, die vom Hauptthread aus gestartet wird, kann man die GUI trotzdem weiter benutzen.
Aber man hängt bis zur Beendigung trotzdem in diesem Button fest.

Ich habe schon versucht einfach alles vom ButtonClick sowie die Arbeit XY in einen Thread zu packen aber das gibt ab und zu hässliche Grafikprobleme. Beispielsweise Labels wo die Caption-Font plötzlich doppelt so groß ist und auch andere Probleme, an die ich mich aber nicht mehr erinnern kann.

Was die Boardmittel angeht: angenommen es soll 5x XY ausgeführt werden (Button > repeat ProcXY (Threads erstellen und WARTEN); ProcSäuberungsarbeiten; until N = 5).
Könnte ich die WARTEN-Sektion nach XY entfernen und eine Message an meinen MessageHandler schicken, der dann anschließend ProcSäuberungsarbeiten aufruft?
Nur wie würde ich das mit der repeat-until-Schleife vereinbaren?

[Neutral General]

Vllt ist für das warten das OnTerminate-Event von TThread das was du brauchst. Du erstellst den Thread, weist das Event zu, startest den Thread und der Button-Klick ist beendet.
Wenn dann der Thread fertig ist landest du automatisch in deinem Eventhandler für OnTerminate und kannst abschließende Sachen machen.

[Glados]

Auf diese Art und Weise bekäme ich die while-Schleife weg. Gute Idee! Werde ich heute Abend mal testen, nachdem ich einen nervigen Bug entfernt habe (hoffentlich).

Wie könnte ich das denn mit der repeat-until-Schleife machen wenn mit nur einem Button-Klick mehrmals XY ausgeführt werden soll?
Die while-Schleife in XY ist ja aktuell dafür da, um die repeat-until-Schleife so lange still zu legen, bis Arbeit XY fertig ist.

[Neutral General]

Kannst du vllt mal kurz genauer erklären was du vorhast?
Das klingt jetzt irgendwie so als sollte das was im Button steht dauerhaft ausgeführt werden nachdem man den Button einmal geklickt hat?

Also einmal draufklicken und dann wiederholt er etwas unendlich lange (bzw. bis der Benutzer das irgendwie anders abbricht)?

In dem Fall müsste die ganze (endlos-)Schleife in einen eigenen Thread.
Bei deinem Codeschnipsel müsstest du aber aufpassen dass du dann da nicht auf GUI-Elemente zugreifen darfst.

Generell bin ich mir nicht sicher ob du da tatsächlich mehrere Threads oder vllt überhaupt Threads brauchst.
Unterm Strich: Kannst du etwas genauer erklären was du vor hast? Das ist grad alles etwas verwirrend und man kann nur grob erahnen was du da vor hast bzw. was du brauchst.

[Glados]

Zitat:

Generell bin ich mir nicht sicher ob du da tatsächlich mehrere Threads oder vllt überhaupt Threads brauchst.

Die brauche ich definitiv. Je nach Arbeitsaufwand wird entschieden, ob nur einer benötigt wird oder mehrere.

Eine Endlosschleife ist das in dem Button nicht.
Es gibt eine definierte Anzahl an Arbeiten die zu erledigen ist. Pro Arbeit wird XY aufgerufen. In XY werden dann die Daten vorbereitet, in Threads verarbeitet und zum Schluss wird aufgeräumt. Dasselbe dann noch einmal. So lange, bis die definierte Anzahl an Arbeiten abgearbeitet ist (repeat-until im Button).

Alles einfach in einen Thread packen würde ich gerne machen. Aber dafür greife ich zwangsweise zu viel auf die VCL zu.

[Uwe Raabe]

Zitat:

Zitat von Glados (Beitrag 1383719)

Alles einfach in einen Thread packen würde ich gerne machen. Aber dafür greife ich zwangsweise zu viel auf die VCL zu.

Dann solltest du letzteres lösen, denn dies ist vermutlich schon der richtige Ansatz. Andererseits spekulieren wir hier alle auch nur :glaskugel:

[Glados]

Ich bin da wenig versiert. Ich würde mir jetzt einfach einen MessageHandler bauen und von überall dort wo ich auf die VCL zugreife, schicke ich dann Messages an den Handler. Der Handler würde dann auf die VCL zugreifen. Ist aber sicher mehr als falsch.

Nur kann ich aus einem Thread heraus ohne Probleme weitere Threads erzeugen?

[Neutral General]

Zitat:

Zitat von Glados (Beitrag 1383735)

Nur kann ich aus einem Thread heraus ohne Probleme weitere Threads erzeugen?

Der Hauptthread ist auch nur ein Thread.
Einfach ein TThread Objekt erstellen und starten.

[TiGü]

Zitat:

Zitat von TiGü (Beitrag 1383673)

Warte doch gar nicht, sondern lass dich vom fertigen Thread benachrichtigen!

Beschäftige dich mal hiermit:
http://docwiki.embarcadero.com/Libra...ad.OnTerminate

Zitat:

Zitat von Neutral General (Beitrag 1383709)

Vllt ist für das warten das OnTerminate-Event von TThread das was du brauchst. Du erstellst den Thread, weist das Event zu, startest den Thread und der Button-Klick ist beendet.
Wenn dann der Thread fertig ist landest du automatisch in deinem Eventhandler für OnTerminate und kannst abschließende Sachen machen.

Zitat:

Zitat von Glados (Beitrag 1383712)

Auf diese Art und Weise bekäme ich die while-Schleife weg. Gute Idee! Werde ich heute Abend mal testen, nachdem ich einen nervigen Bug entfernt habe (hoffentlich).

Das nächste Mal schreibe ich einfach in großer, rot blinkender Schrift...:shock:
Man muss auf die Links auch klicken, lesen und verstehen. :roll:

[Glados]

Zitat:

Man muss auf die Links auch klicken, lesen und verstehen.

Ich kenne OnTerminate. Ich habe oben auch extra geschrieben, dass ich mich benachrichtigen lassen kann, sobald ein Thread beendet ist bzw. sobald der letzte im Multitasking beendet ist ;)

Das Problem ist aber repeat-until. Denn irgendwo muss ich ja warten bevor der nächste Job gestartet wird.

[TiGü]

Zitat:

Zitat von Glados (Beitrag 1383761)

Zitat:

Man muss auf die Links auch klicken, lesen und verstehen.

Zitat:

Zitat von Glados (Beitrag 1383761)

Ich kenne OnTerminate. Ich habe oben auch extra geschrieben, dass ich mich benachrichtigen lassen kann, sobald ein Thread beendet ist bzw. sobald der letzte im Multitasking beendet ist ;)

Unwahrscheinlich, denn dann hättest du nicht dieses Konstrukt mit der while-Schleife.
Zum Verständnis: Mein Beitrag ist Nummer #5 hier im Thread.

Zitat:

Zitat von Glados (Beitrag 1383761)

Das Problem ist aber repeat-until. Denn irgendwo muss ich ja warten bevor der nächste Job gestartet wird.

Es wäre am Einfachsten, dass du ein Beispiel-Projekt hier hoch lädst.
Natürlich musst du nicht konkret zeigen was du du tust.
Eine Art Ersatz-Job (Primzahlen berechnen, Sleep, etc.) tut es auch.
Anhand dessen kann man die konkreten Lösungsstrategien entwickeln.

[Glados]

Zitat:

Unwahrscheinlich, denn dann hättest du nicht dieses Konstrukt mit der while-Schleife.

Es ist sogar sehr wahrscheinlich, dass ich OnTerminate kenne.

Ich habe insgesamt 2 Schleifen, wie ich oben irgendwie versucht habe zu erklären. Ich habe jetzt aber keine Lust mich zu streiten :|
Aber eines weiß ich: ich kann mein Problem nicht korrekt erklären und ich weiß genau was OnTerminate macht.

Zitat:

Ich bin da wenig versiert. Ich würde mir jetzt einfach einen MessageHandler bauen und von überall dort wo ich auf die VCL zugreife, schicke ich dann Messages an den Handler. Der Handler würde dann auf die VCL zugreifen. Ist aber sicher mehr als falsch.

So in etwa aktualisiere ich bereits eine Progressbar aus einem Thread heraus.
Ist das da oben denn überhaupt der richtige Ansatz, um auf VCL-Komponenten aus einem Thread heraus zuzugreifen?