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 von Glados:

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 von Glados:

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

[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 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.