Delphi: TParallel.For με ασφαλές για νήματα UI προόδου (TThread.Queue) χωρίς deadlocks

Όποιος σε Delphi θέλει να παραλληλοποιήσει υπολογιστικά ή I/O-εντατικά jobs, καταλήγει γρήγορα στη Parallel Programming Library (PPL) και συγκεκριμένα στο TParallel.For. Το αποτέλεσμα συχνά είναι άμεσα μετρήσιμο – μέχρι να επιχειρήσει κανείς την ίδια στιγμή να ενημερώσει «γρήγορα» ένα Progress-UI. Εδώ ακριβώς ανακύπτουν οι τυπικές παγώσεις: φαινομενικά τυχαία freezes του UI, μια ProgressBar που πηδάει προς τα πίσω ή ένας πλήρης deadlock μόλις προχωρήσει κανείς βήμα‑βήμα στο debugger.

Σε αυτό το άρθρο πρόκειται για TParallel.For threadsichere Progress-UI: ένα ανθεκτικό πρότυπο που λειτουργεί σε VCL και FMX, συγκεντρώνει καθαρά τις ενημερώσεις του UI μέσω TThread.Queue, λαμβάνει υπόψη Cancel/Abort και αποφεύγει συστηματικά τις πιο συνηθισμένες παγίδες deadlock. Η έμφαση είναι στην επιχειρησιακή πραγματικότητα: αναπαραγώγιμη συμπεριφορά, σαφείς αρμοδιότητες και ενδείξεις για debugging που βοηθούν ακόμα κι αν το σφάλμα εμφανίζεται «μόνο στους πελάτες».

Γιατί το Progress-UI με TParallel.For αποτυγχάνει τόσο συχνά

TParallel.For τρέχει τυπικά σε worker‑threads από το Delphi‑threadpool. Αυτά τα threads δεν επιτρέπεται να αγγίζουν απευθείας controls της VCL ή της FMX, γιατί τα UI‑frameworks (βρόχος μηνυμάτων, handles παραθύρου, rendering) είναι δεμένα με τον Main Thread. Ακόμη και μια φαινομενικά ακίνδυνη εντολή ProgressBar.Position := … μέσα από έναν worker μπορεί να οδηγήσει σε μη καθορισμένη συμπεριφορά: σποραδικά AVs, παγωμένα παράθυρα ή «τρεμάμενες» ενημερώσεις.

Η προφανής επιδιόρθωση είναι συχνά το TThread.Synchronize. Αυτό διορθώνει την ασφάλεια των threads, αλλά σε παράλληλες βρόχους οδηγεί γρήγορα σε άλλο πρόβλημα: δημιουργεί έναν σειριακό σημείο συμφόρησης. Κάθε worker περιμένει τον UI‑thread, ο οποίος με τη σειρά του είναι απασχολημένος με το rendering και την εκτέλεση των κλήσεων Synchronize. Υπό φόρτο αυτό μοιάζει με deadlock – ακόμα κι αν πρόκειται «μόνο» για φαινόμενο starvation/lockstep.

Και υπάρχει η κατηγορία του πραγματικού deadlock: ο Main Thread περιμένει (π.χ. μέσω WaitFor, Task.Wait ή έμμεσα μέσω μπλοκαριστικών κλήσεων) το τέλος της παράλληλης λειτουργίας, ενώ οι worker‑threads προσπαθούν να στείλουν εργασία στον Main Thread μέσω Synchronize ή λόγω ακατάλληλης χρήσης της Queue. Αποτέλεσμα: ο Main Thread περιμένει τους Worker και οι Worker περιμένουν τον Main Thread.

TThread.Queue vs. TThread.Synchronize: η πρακτική διαφορά

Και οι δύο μηχανισμοί χρησιμοποιούνται για να εκτελέσουν με ασφάλεια κώδικα στον Main Thread. Η διαφορά βρίσκεται στη σημασιολογία του περιμένειν:

• TThread.Synchronize: Ο καλών worker περιμένει μέχρι ο Main Thread να εκτελέσει τον κώδικα. Αυτό είναι «συγχρονικό», αυξάνει τις λανθάνουσες και αποτελεί κλασικό συστατικό για deadlocks όταν ο Main Thread είναι μπλοκαρισμένος.
• TThread.Queue: Ο Worker τοποθετεί τον κώδικα μόνο σε μια Warteschlange για το κύριο νήμα και συνεχίζει να τρέχει. Αυτό είναι „asynchron“, αποσυνδέει τα νήματα και είναι σε Parallel-Szenarien σχεδόν πάντα η καλύτερη προεπιλεγμένη Wahl – sofern man die Update-Frequenz kontrolliert.

Wichtig: Queue ist kein Freifahrtschein. Wenn Sie in jeder Iteration einer Schleife ein Queue-Update schicken, überfluten Sie die Main-Thread-Queue. Dann hängt die UI zwar nicht wegen Deadlock, aber wegen schierer Menge an Nachrichten. Die UI wirkt „zäh“, und das Ende der Verarbeitung verzögert sich, weil noch hunderte oder tausende UI-Updates nachlaufen.

Der Randfall, der wirklich wehtut: Warten im UI-Thread

In Unternehmensanwendungen sieht man häufig folgenden Ablauf: Button „Start“ klickt, UI wird deaktiviert, ProgressDialog geht auf, dann wird synchron „gewartet“, bis alles fertig ist, um anschließend wieder zu aktivieren. Dieses Muster ist der Kern vieler Deadlocks.

Typische Varianten (je nach Codebasis):

• Main Thread startet TParallel.For und ruft danach eine blockierende Wartelogik auf (direkt oder indirekt).
• Ein ProgressDialog ruft im Constructor oder OnShow eine Routine auf, die intern wartet.
• Ein Abbrechen-Button setzt zwar ein Flag, aber der Main Thread bleibt trotzdem in einem Warteloop hängen.

Wenn Worker-Threads in dieser Zeit Synchronize benutzen, ist der Deadlock praktisch garantiert. Mit Queue kann es ebenfalls hängen, wenn der Main Thread blockiert und keine Messages pumpt – denn dann wird auch die Queue nicht abgearbeitet.

Die betriebsfeste Konsequenz lautet: Der Main Thread darf nicht blockierend auf die Parallel-Schleife warten, wenn parallel UI-Updates benötigt werden. Stattdessen muss die Verarbeitung entweder vollständig in einen Hintergrund-Task ausgelagert werden, oder man organisiert ein „asynchrones Ende“ (Callback/Queued Abschlussaktion), das die UI am Schluss wieder freigibt.

Sauberer Ansatz: Progress nur aggregiert, UI-Updates gedrosselt

Ein robustes Muster besteht aus drei klar getrennten Verantwortlichkeiten:

• Worker-Threads machen die eigentliche Arbeit pro Element/Index. Sie melden nur Fortschritt in einer threadsicheren Form (Zähler, Queue, Thread-safe Queue).
• Aggregator (oft: Main Thread oder ein dedizierter Timer im UI) berechnet aus dem Fortschritt einen UI-Status (Position, Text, ETA) und aktualisiert Controls. So vermeiden Sie 1:1-Updates pro Iteration.
• Abschluss (ebenfalls im Main Thread): UI reaktivieren, Ergebnis anzeigen, Fehler zusammenfassen, Ressourcen freigeben.

Γιατί αυτή η διαχωρισμός λειτουργεί τόσο καλά: Ο φόρτος εργασίας μπορεί να είναι υψηλής συχνότητας (χιλιάδες στοιχεία), αλλά το UI χρειάζεται μόνο λίγες ενημερώσεις ανά δευτερόλεπτο. Στην πράξη αρκούν 5–10 ενημερώσεις/δευτερόλεπτο, σε πολύ γρήγορα jobs ακόμη και 2–4. Οτιδήποτε πάνω από αυτό είναι συνήθως μόνο οπτικός θόρυβος και κοστίζει χρόνο CPU στη message pump.

Threadsicher zählen: Atomic statt Lock

Για μια απλή ProgressBar συχνά αρκεί ένας ατομικός μετρητής. «Ατομικός» σημαίνει: το Increment και το Read συμβαίνουν χωρίς race condition, τυπικά μέσω TInterlocked. Με αυτόν τον τρόπο αποφεύγετε Locks (Critical Sections) στο hot path του βρόχου.

Δοκιμασμένη βασική ιδέα:

• Το συνολικό μέγεθος είναι γνωστό εκ των προτέρων (π.χ. αριθμός εγγραφών, αρχείων, IDs).
• Κάθε επανάληψη αυξάνει έναν DoneCounter ατομικά.
• Ένας UI-Timer διαβάζει περιοδικά τον counter και θέτει το ProgressBar.Position.

Πλεονέκτημα: Καμία TThread.Queue ανά στοιχείο, καμία υπερφόρτωση του UI. Μειονέκτημα: Δεν έχετε λεπτομερείς μηνύματα ανά στοιχείο (π.χ. όνομα αρχείου). Γι’ αυτό μπορείτε να προσθέσετε μια δεύτερη, ρυθμισμένη ενημέρωση κατάστασης (βλέπε επόμενο τμήμα).

Statusmeldungen ohne Spam: „letzter Status gewinnt“

Εάν θέλετε επιπλέον να εμφανίσετε ένα σύντομο κείμενο (τρέχον στοιχείο, φάση, μήνυμα σφάλματος), χρειάζεται επίσης ένα πρότυπο που να μην πλημμυρίζει το UI σε κάθε βήμα του worker. Στην πράξη λειτουργεί πολύ καλά το «η τελευταία κατάσταση κερδίζει»:

• Ο Worker γράφει μια πληροφορία κατάστασης σε μια νήμα-ασφαλή δομή (π.χ. ατομικά ανταλλάξιμο String, ή προστατευμένο με μικρό Lock).
• Ο UI-Timer υιοθετεί περιοδικά την πιο πρόσφατη κατάσταση σε ένα Label.

Έτσι το UI παραμένει ανταποκρίσιμο, και παρόλα αυτά βλέπετε ότι «κάτι συμβαίνει». Σημαντικό εδώ είναι λιγότερο το ίδιο το String και περισσότερο η διάρκεια ζωής: μην μεταφέρετε αναφορές σε βραχυζωϊκά αντικείμενα από Worker-Threads στον UI-Thread. Εάν περνάτε αντικείμενα, διευκρινίστε ρητά την ιδιοκτησία.

TParallel.For threadsichere Progress-UI mit TThread.Queue: ein robustes Muster

Υπάρχουν σενάρια όπου ένας UI-Timer μόνος του δεν αρκεί: π.χ. όταν στο τέλος θέλετε να ενεργοποιήσετε με βεβαιότητα ακριβώς μία ενημέρωση «Fertig», ή όταν η ενημέρωση του UI είναι ένα πιο σύνθετο βήμα (π.χ. εγγραφή σε παράθυρο log, αλλά περιορισμένη). Τότε το TThread.Queue είναι κατάλληλο — αλλά όχι ανά επανάληψη, παρά στοχευμένα.

Μια πρακτική προσέγγιση είναι μια Queue μόνο για γεγονότα χαμηλής συχνότητας:

• Start-Event (προετοιμασία UI, απενεργοποίηση κουμπιών)
• Περιοδικά Progress-Events (το πολύ κάθε X χιλιοστά του δευτερολέπτου)
• Fehler-Events (προαιρετικά συσσωρευμένα)
• Done-Event (επαναφορά του UI, εμφάνιση αποτελέσματος)

Την περιοδικότητα δεν την επιτυγχάνετε μέσω του UI-Thread, αλλά ήδη στο context του Worker: αφήνετε τους Worker να queueν ένα UI-Update μόνο όταν έχει περάσει αρκετός χρόνος από την τελευταία ενημέρωση του UI. Για αυτό ταιριάζει μια μονοτονική πηγή χρόνου (π.χ. TickCount) συν ένα ατομικό πεδίο «last update».

Σημαντικό: Η ίδια η ενημέρωση του UI πρέπει να είναι «γρήγορη». Ακριβοί υπολογισμοί, αρχείο-I/O ή προσβάσεις σε βάσεις δεδομένων δεν ανήκουν στον queued UI-callback. Ο callback πρέπει μόνο να διαβάζει καταστάσεις και να ορίζει Controls.

Cancel-Handling: Abbrechen ohne Hänger

Σε πραγματικές εφαρμογές η ακύρωση δεν είναι προαιρετική. Σημαντικό: το Cancel δεν είναι «Kill», αλλά ένα συνεργατικό τερματισμό. Οι Worker πρέπει τακτικά να ελέγχουν αν έχει τεθεί ένα σήμα ακύρωσης και στη συνέχεια να αποχωρούν καθαρά. Στο Delphi υπάρχουν γι’ αυτό διάφοροι τρόποι (ανάλογα με την PPL-Konstruktion): ένα ξεχωριστό Volatile-Flag, ένας ατομικός Boolean, ή ένα cancellation-σχήμα μέσω Tasks (ανάλογα με την έκδοση και τη δομή του Delphi).

Für den Betrieb wichtig sind zwei Regeln:

• Cancel muss schnell sichtbar werden: Prüfen Sie das Abbruchflag an sinnvollen Stellen, nicht nur am Ende einer Iteration, wenn die Iteration auch mal Sekunden dauern kann.
• Cancel muss aufräumen: Offene Handles, temporäre Dateien, Transaktionen oder Locks dürfen nicht liegen bleiben. Das heißt: In jeder Worker-Iteration sind try/finally-Blöcke Pflicht, wenn Ressourcen beteiligt sind.

UI-seitig sollte Cancel nur ein Signal setzen und die UI in einen „Stopping…“-Zustand bringen. Die eigentliche Beendigung und das Reaktivieren der UI passieren dann im Done-Event, nicht sofort beim Klick.

Deadlocks vermeiden: die häufigsten Fallen in der Praxis

Falle 1: WaitFor/Task.Wait im Main Thread

Wenn der Main Thread blockiert, kann er keine Queue-Callbacks ausführen und keine Messages verarbeiten. Das wirkt wie ein Deadlock, auch wenn die Worker korrekt weiterlaufen. Lösung: Keine blockierenden Waits im UI-Thread. Stattdessen Abschlussaktion über TThread.Queue oder eine Ereignissteuerung (z. B. Timer prüft „fertig“).

Falle 2: Synchronize innerhalb eines Locks

Ein Klassiker: Worker hält eine Critical Section, ruft dann Synchronize, und im UI-Callback wird (direkt oder indirekt) wieder dieselbe Critical Section benötigt. Ergebnis: Kreis warten. Die Regel ist simpel: Keine UI-Übergabe (Synchronize/Queue) aus einem gehaltenen Lock heraus. Wenn ein Lock nötig ist, holen Sie alle Daten erst in lokale Variablen, verlassen den Lock, dann queue’n Sie.

Falle 3: UI-Callback triggert Reentrancy

Manchmal ist das UI-Update selbst nicht „harmlos“: Setzen von Properties kann Events auslösen (OnChange, OnResize), die wiederum Logik anwerfen, die auf Worker-Zustände zugreift. Das ist kein Deadlock im engeren Sinne, aber führt zu schwer erklärbaren Hängern und Race Conditions. Abhilfe: UI-Updates in „stille“ Pfade legen (Events temporär deaktivieren) oder Reentrancy-Guards nutzen (z. B. atomarer Guard für Update-Phase).

Falle 4: Zu viele queued Updates

Auch ohne Waits kann die UI „stehen“, wenn Sie zehntausende queued Callbacks erzeugen. Symptome: ProgressBar rennt lange nach, Fenster reagiert träge, CPU im Main Thread hoch. Lösung: Drosseln (Zeitfenster), aggregieren (Counter), oder eine echte Producer/Consumer-Struktur, bei der nur ein UI-Update „pending“ sein kann (Coalescing).

Wenn es komplizierter wird: Ergebnisse sammeln, Fehler bündeln, Reihenfolgen garantieren

TParallel.For ist ideal, wenn Iterationen unabhängig sind. In Business-Software sind Iterationen aber oft nur „weitgehend“ unabhängig: Sie lesen Dateien, rufen REST-APIs, schreiben Datenbankzeilen. Dann müssen Sie drei zusätzliche Punkte sauber planen:

• Thread-sichere Ergebnis-Sammlung: Entweder pro Thread ein lokaler Buffer (am Ende zusammenführen) oder eine threadsichere Queue/Collection. Locks im Hot Path vermeiden.
• Διαχείριση σφαλμάτων: Πρέπει να συλλεχθούν οι Exceptions από τα Worker-Threads. Στην πράξη αποδίδει: καταγράψτε την πρώτη Exception και ενεργοποιήστε Cancel, ή συγκεντρώστε όλες τις Exceptions και εμφανίστε τες στο τέλος συνοπτικά.
• Σειρά: Εάν η έξοδος χρειάζεται σταθερή σειρά (π.χ. logs κατά index), η παράλληλη επεξεργασία με μεταγενέστερη ταξινόμηση είναι συχνά πιο απλή από το «thread-sicheres geordnetes Einfügen».

Για το UI αυτό σημαίνει: Μην εμφανίζετε κάθε μεμονωμένο μήνυμα σφάλματος αμέσως. Αυτό οδηγεί σε κόλαση modal διαλόγων. Συγκεντρώστε τα σφάλματα (π.χ. λίστα από Strings) και εμφανίστε στο τέλος μια σύνοψη ή ένα εξαγώγιμο log.

Debugging: Πώς να κάνετε τον Deadlock πραγματικά ορατό

Οι deadlocks σε παράλληλο κώδικα είναι απογοητευτικοί, επειδή στον debugger μπορεί να φαίνονται διαφορετικά απ’ ό,τι στο release. Παρόλα αυτά υπάρχουν μερικοί πρακτικοί μοχλοί:

Χρησιμοποιήστε το παράθυρο Threads και τα Call Stacks

Όταν το UI «παγώνει», ελέγξτε όλα τα threads: Πού βρίσκεται ο Main Thread; Περιμένει; Είναι σε message-loop; Πού βρίσκονται οι Worker-Threads; Εάν Workers «κολλάνε» σε Synchronize, η αιτία σχεδόν πάντα είναι «Main Thread μπλοκαρισμένος» ή «ο Main Thread χρειάζεται ένα lock».

Επισήμανση σημείων Queue-/Synchronize

Τοποθετήστε στοχευμένο logging στα σημεία παράδοσης (πριν το Queue, στο Queue-callback, στο τέλος της επανάληψης). Στον παραγωγικό έλεγχο αυτό είναι συχνά πιο χρήσιμο από breakpoints, γιατί το timing είναι κρίσιμο. Φροντίστε το ίδιο το logging να είναι thread-safe και μη αποκλειστικό (π.χ. όχι άμεση έξοδος log στο UI από Worker-Threads).

Μετρήστε τον χρόνο από την τελευταία ενημέρωση

Όταν το UI «παγώνει», μπορεί απλώς να έχει υπερβολικά πολλές ενημερώσεις για να επεξεργαστεί. Μετρήστε λοιπόν στον Main Thread πόσες φορές ανά δευτερόλεπτο εκτελείτε ένα UI-update και πόση διάρκεια καταλαμβάνει. Μόλις τα UI-callbacks χρειάζονται πάνω από λίγα milliseconds, απαιτείται ρύθμιση ροής ή απλοποίηση.

Πότε αξίζει πραγματικά το TParallel.For με Progress-UI?

Η παράλληλη επεξεργασία δεν είναι αυτοσκοπός. Αξίζει ιδιαίτερα όταν:

• οι επαναλήψεις είναι αρκετά μεγάλες (χιλιοστά του δευτερολέπτου έως δευτερόλεπτα), έτσι ώστε το overhead του threadpool να γίνεται ασήμαντο,
• η εργασία είναι CPU-βαριά (Parsing, Kompression, Hashing) ή έχει I/O που παραλληλοποιείται καλητέρα (πολλά αρχεία, πολλαπλά HTTP-Requests με όρια),
• έχετε σαφή στρατηγική για Cancel και χειρισμό σφαλμάτων,
• οι απαιτήσεις του UI μπορούν να δεχθούν συγκεντρωμένη ένδειξη προόδου.

Αξίζει λιγότερο όταν κάθε επανάληψη είναι εξαιρετικά σύντομη (Mikro-Operationen) ή όταν όλες οι επαναλήψεις εξαρτώνται από τον ίδιο στενωπό (μια σειριακή DB-transaction, ένα global lock, ένα μόνο αρχείο). Τότε ο πιο αποτελεσματικός μοχλός συχνά είναι: βελτιστοποίηση αλγορίθμου, batching, μείωση πρόσβασης στα δεδομένα ή ρητή αποσύνδεση του στενωπού.

Πρακτικός κατάλογος ελέγχου: Πώς να παραμείνει το UI σταθερό

• Ο Main Thread δεν μπλοκάρεται: ούτε Waits, ούτε μεγάλοι βρόχοι χωρίς Message Pump.
• Οι Worker δεν πειράζουν Controls: καμία πρόσβαση σε VCL/FMX εκτός του UI-Thread.
• Τα UI-updates είναι ρυθμισμένα: Counters/Timer ή coalesced Queue-Updates αντί για ενημέρωση ανά επανάληψη.
• Καμία κλήση Synchronize μέσα από Locks.
• Το Cancel είναι συνεργατικό, συχνά ελεγχόμενο και καθαρίζει σωστά.
• Οι Exceptions συλλέγονται και στο τέλος επεξεργάζονται με τάξη.

Συμπέρασμα: Αποσυνδέστε με Queue, σταθεροποιήστε με Aggregation

Μια ανθεκτική Progress-UI σε TParallel.For δεν προκύπτει με το «να βάλετε κάπου ένα Synchronize», αλλά με ένα σαφές αρχιτεκτονικό πρότυπο: οι workers λειτουργούν ανεξάρτητα, το κύριο νήμα παραμένει ελεύθερο και επεξεργάζεται μόνο λίγες, γρήγορες ενημερώσεις της διεπαφής. TThread.Queue είναι το σωστό εργαλείο όταν το χρησιμοποιείτε στοχευμένα και με περιορισμό. Για «βαριά» ή ασταθή συμπεριφορά σχεδόν πάντα ευθύνονται δύο αιτίες: το κύριο νήμα μπλοκάρει κάπου — ή πνίγεται σε υπερβολικά πολλές ενημερώσεις που βρίσκονται σε ουρά.

Όταν στήσετε το μοτίβο σωστά (Counter/Coalescing, Cancel-Flag, Abschluss-Callback), αξίζει να το εφαρμόσετε σε πολλά σημεία μιας ώριμης Delphi-εφαρμογής: εισαγωγή/εξαγωγή, ελέγχους δεδομένων, εργασίες αρχείων και API – όλα γίνονται πιο ανταποκρίσιμα χωρίς να αποκτάτε νέα deadlocks με κάθε ενημέρωση προόδου.

Εάν χρειάζεστε υποστήριξη για τη σταθεροποίηση παράλληλου κώδικα, για το debugging παγώσεων του UI ή για τον καθαρό εκσυγχρονισμό ώριμων Delphi-εφαρμογών: Επικοινωνήστε μαζί μας.

Για αυτό το θέμα είναι επίσης σημαντικές η Delphi Parallel Programming Library και Tthread.queue Vs Synchronize. Το άρθρο τοποθετεί αυτές τις πτυχές με σαφήνεια και δείχνει τι μετρά στην καθημερινή χρήση.

Συζητήστε έργο ή πρόγραμμα εκσυγχρονισμού με Net-Base.