![]() |
TThread, TTask usw. oder OmniThreadLibrary?
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? |
AW: TThread, TTask usw. oder OmniThreadLibrary?
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.
|
AW: TThread, TTask usw. oder OmniThreadLibrary?
Zitat:
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:
|
AW: TThread, TTask usw. oder OmniThreadLibrary?
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? |
AW: TThread, TTask usw. oder OmniThreadLibrary?
Warte doch gar nicht, sondern lass dich vom fertigen Thread benachrichtigen!
Beschäftige dich mal hiermit: ![]() |
AW: TThread, TTask usw. oder OmniThreadLibrary?
Ohne das Problem auch nur ansatzweise analysiert zu haben, fällt mir hier der
Delphi-Quellcode:
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.
TOmniEventMonitor
|
AW: TThread, TTask usw. oder OmniThreadLibrary?
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 |
AW: TThread, TTask usw. oder OmniThreadLibrary?
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? |
AW: TThread, TTask usw. oder OmniThreadLibrary?
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. |
AW: TThread, TTask usw. oder OmniThreadLibrary?
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. |
AW: TThread, TTask usw. oder OmniThreadLibrary?
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. |
AW: TThread, TTask usw. oder OmniThreadLibrary?
Zitat:
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. |
AW: TThread, TTask usw. oder OmniThreadLibrary?
Zitat:
|
AW: TThread, TTask usw. oder OmniThreadLibrary?
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? |
AW: TThread, TTask usw. oder OmniThreadLibrary?
Zitat:
Einfach ein TThread Objekt erstellen und starten. |
AW: TThread, TTask usw. oder OmniThreadLibrary?
Zitat:
Zitat:
Zitat:
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: |
AW: TThread, TTask usw. oder OmniThreadLibrary?
Zitat:
Das Problem ist aber repeat-until. Denn irgendwo muss ich ja warten bevor der nächste Job gestartet wird. |
AW: TThread, TTask usw. oder OmniThreadLibrary?
Zitat:
Zum Verständnis: Mein Beitrag ist Nummer #5 hier im Thread. Zitat:
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. |
AW: TThread, TTask usw. oder OmniThreadLibrary?
Zitat:
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:
Ist das da oben denn überhaupt der richtige Ansatz, um auf VCL-Komponenten aus einem Thread heraus zuzugreifen? |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:55 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz