Wie beende ich einen TThread freundlich und notfalls gewaltsam?

[Der schöne Günther]

Hallo-

Zum immer näher rückenden Wochenende möchte ich Euch noch eine Freude mit einer Thread-Frage machen, ich hoffe, Ihr habt die heutige Frage zum Thema Threads noch nicht vermisst. 8-)

Folgendes weiß ich bereits:

1. Der TThread sollte sich immer selbst beenden indem die Methode
   Delphi-Quellcode:

   Execute

   endet.
2. Um herauszufinden, ob der TThread nun wirklich endgültig tot ist, kann man mit dem Setzen der
   Delphi-Quellcode:

   onTerminate

   -Methode bewerkstelligen. Diese Methode setzt z.B. eine Variable done auf True

Das Problem:
Der Thread ackert sich stellenweise durch Aufrufe die gerne mal eine Viertelsekunde blockieren. Ich möchte einstellen, dass sich der Destruktor des Objekts dem der TThread "gehört" (der TThread ist eine innere Klasse) sich nur eine bestimmte Zeit geduldet und dann rabiat wird.

Ich finde nichts, was TThread anbietet, nur die ultimative WinAPI-Funktion

Delphi-Quellcode:

TerminateThread

. Ja, der Thread steckt möglicherweise in einem kritischen Abschnitt. Ja, der Thread hat möglicherweise das Betreten kritischer Abschnitte verursacht, von denen ich nichts weiß.

Aber etwas besseres fällt mir nicht ein. Und es gefällt mir nicht, letztendlich doch eine WinAPI-Funktion anfassen zu müssen, aber das ist nebensächlich.

Es läuft also folgendermaßen ab:

Delphi-Quellcode:

destructor TMeineKlasse.Destroy;
const
   waitIterations: UInt = 500000;
var
   waitCounter: UInt;
begin

   // Sei freundlich zum Thread
   pollingThread.Terminate();

   waitCounter := 0;
   // Die 500.000 Iterationen sind sind praktisch immer zu wenig
   while (not pollingThread.done) and (waitCounter < waitIterations) do begin
      // Werde ich im Endeffekt wahrscheinlich nicht verwenden, das Objekt 
      // soll sich dem komischen Application-Objekt nicht herumplagen:
      Application.ProcessMessages(); 
      
      Inc(waitCounter);
      Sleep(0);
   end;

   // Thread hat sich nicht in geforderter Zeit beenden können
   if waitCounter = waitIterations then
      //Keine Ahnung bzgl. ExitCode, Null passt sicher immer
      TerminateThread(pollingThread.Handle, 0); 

   [Weiteres Aufräumen]

   pollingThread.Free();
   myCriticalSection.Free();

   inherited Destroy();

end;

Habe ich das so richtig gemacht? Natürlich kann man sich darüber streiten, wie schnell man so rabiat werden sollte, aber die Hintertür möchte ich mir auf jeden Fall offen lassen. Wer weiß, vielleicht hat sich der Thread ja auch aufgehangen...

[Furtbichler]

Alles Mist. :-)

Sorge einfach dafür, das der Thread ordentlich terminiert. Alles andere ist absoluter Müll. Ich weiß, wovon ich rede, ich wollte das selbst mal so machen. Aber es ist bescheuert, glaube mir.

[Der schöne Günther]

Ich tue alles menschenmögliche. Und notfalls hänge den Hauptthread auch drei Sekunden auf um so lange auf den Thread zu warten.

Aber irgendwann muss doch wirklich mal Schluss sein?

Alternativ schleppe ich das TThread-Objekt bis zum Schluss als Speicherleiche mit, allerdings könnte das Objekt durchaus mehrere male am Tag zerstört und neu erstellt werden und die Software muss mehr oder weniger 24/7 laufen :?
Irgendwann ist da dann auch mal eine Grenze erreicht...

[tsteinmaurer]

Du musst im Execute des Threads regelmäßig das Terminated Flag abfragen und z.b. mit Exit rausspringen. Im aufrufenden Thread (Main-Thread?) rufst du nach Terminate einfach die WaitFor Methode des Thread-Objekts auf. Dies hält dir dann den aufrufenden Thread solange an, bis der Thread beendet wurde. Wenn du FreeOnTerminate := False des Threads gesetzt hast, dann musst du das Thread-Objekt auch noch mit Free freigeben.

[Der schöne Günther]

Danke für die Antworten.

Wie gesagt, wie man es richtig macht, habe ich anscheinend verstanden.

Jetzt geht es um den Fall, dass im Thread etwas falsch läuft. Dass er möglicherweise nie dazu kommen wird, sich um sein

Delphi-Quellcode:

Terminated

zu scheren da er irgendwo hängt oder möglicherweise abgestürzt ist.:wink:

[QuickAndDirty]

Zitat:

Zitat von Der schöne Günther (Beitrag 1208440)

Danke für die Antworten.

Wie gesagt, wie man es richtig macht, habe ich anscheinend verstanden.

Jetzt geht es um den Fall, dass im Thread etwas falsch läuft. Dass er möglicherweise nie dazu kommen wird, sich um sein

Delphi-Quellcode:

Terminated

zu scheren da er irgendwo hängt oder möglicherweise abgestürzt ist.:wink:

Easy! Mach ne Anwendung draus. Wenn die nicht auf IPC reagiert...kannst sie terminieren.

[Bummi]

Du kannst ja mal hier nachlesen TerminateThread function warum man einen Thread nicht einfach "killen" sollte.

[Der schöne Günther]

Das habe ich natürlich schon alles verschlungen 8-)

Wie gesagt: Die Methode soll - Bei allem was heilig ist! - natürlich nicht Standard sondern nur der allerletzte Ausweg sein. Quasi ein sinkendes Schiff dessen letzte Rettung es ist, die Passagiere von Bord zu werfen damit wenigstens die Mannschaft noch heil nach Hause kommt.

(Oder so ähnlich)

[Furtbichler]

Nee, Günther.

Programme sollen einfach richtig sein. Wenn da was irgendwie ne viertel Stunde rumrödelt und vielleicht 'abgestürzt' ist, dann hast Du einfach irgendetwas nicht richtig gemacht. Nichts stürzt einfach so irgendwie irgendwo ab. Programme sind blöderweise deterministisch. Leider wollen wir (Programmierer) das nicht wahrhaben.

Sich damit abzufinden, das irgendwas irgendwie ab und zu mal abstürzt ist ...

nee, Günther.

:-D

[Bjoerk]

Hallo schöner Günther,

wo hast du denn das Logo, das einem so herrlich die Augen rausgebrannt hat? :-D

Ich benutze Threads vergleichsweise selten, aber wie wär's mit 2 Events.

Delphi-Quellcode:

procedure TMyThread.Execute;
begin
  try
    try
      if Assigned(FThreadActive) then
        FThreadActive(Nil);
      ..
    except
      on E: Exception do
        ShowMessage('Interner Fehler TMyThread');
    end;
  finally
    if Assigned(FThreadInactive) then
      FThreadInactive(Nil);
  end;
end;

[Medium]

Ich kann Günthers Ansinnen schon gut verstehen. Wir haben auch Software im Einsatz, bei der die aller aller erste Prio ist, dass es LÄUFT. Es gibt Threads, die mit anderer Hardware via TCP sprechen. Leider verhält sich die Zugriffs-Lib (eine externe DLL) nicht immer so arg zuverlässig, so dass es z.B. beim Herausziehen des Netzwerkkabels durchaus passieren kann, dass ein Kommunikationsversuch bis in alle Ewigkeit wartet. Auch, wenn man das Kabel wieder rein stöpselt. (Das ist ein Beispiel, ich will jetzt nicht von euch hören, wie ich das Einstecken des Kabels von Windows mitgeteilt bekomme.) Da es für uns nicht wirtschaftlich ist diesen in 2 Jahren 1 Mal vorkommenden Fall damit zu behandeln, dass wir die externe (in C geschriebene) Lib a) verstehen und b) debuggen und dazu noch eine entsprechende Compilerumbegung zu erstellen (wir nutzen sonst kein C), war die "freundlichste" Lösung: Ein weiterer Thread als Watchdog, die den anderen nach einem Timeout im Zweifel per WinAPI wegballert und neu startet. (Solle dann immer noch keine Verbindung bestehen, wird dort zumindest brav eine entsprechende Rückmeldung gegeben.)

Bei aller Liebe zum Richtigmachen: Stellt keinem in Abrede, dass es wirtschaftlich sehr vorteilhafte, verhältnismäßige, und gar funktional vertretbare Fälle gibt, zu dessen Ursachen man ggf. nichtmals Zugang hat. Man muss natürlich sehr genau abwägen, und wissen was im schlimmsten Fall dabei schief gehen kann. Wenn aber 24/7 Funktion ohne Aufsicht das Credo ist, und man es in JEDEM Fall sicher stellen muss selbst wenn eine Handgranate im Server explodiert, dann ist ein weggeschossener Thread mit sauberem Neuaufsetzen die beste Alternative zwischen möglicherweise Wochen an (unbezahltem) Entwicklungsaufwand in Fremdcode in einer Sprache von der man nicht viel mehr als den Namen und grobe Züge kennt, und unvorhersehbaren aber immerhin sauberen Totalausfällen. Zumindest wenn man mit dem Programm nicht gerade eine Rakete oder ein AKW steuert.

Das akademische Ideal sollte nach Möglichkeit immer angestrebt werden, in der echten Welt gibt es aber leider auch so Sachzwänge wie Deadlines, Budgets und ggf. auch einfach andere Prioritätensetzung als eben das betroffene kleine Subsystem. Ich will üble Hacks hier nicht proklamieren, ich hoffe dass ich nicht so verstanden werde! Aber gerade bei Threads, die "von aussen" weggehängt werden bin ich ein wenig gebranntes Kind, und kann den Sinn und Nutzen einfach voll verstehen.

Wenn keine IPC oder andere externe Kommunikation dabei ist, schaut es wieder etwas anders aus: So lange ich mich voll und ganz in Delphi bewege, kann ich solche Sachen quasi immer hübsch und sauber behandeln. (Ausnahme: Nur als DCU vorliegende Komponenten, die eine while true do... Schleife haben.) Wenn man nach dem Verursachenden Aufruf einfach nicht mehr dazwischen kommt - ja was bleibt einem denn anderes!? Also bitte ein wenig mehr piano hier. Die Frage ist legitim, das Mittel je nach Fall auch. Der Zweck ohnehin.

[Der schöne Günther]

Bislang sah ich mich Selbst als Einmannwolfsrudel, aber als ich deinen Beitrag las wusste ich: Er gehört zu mir. Und mein Wolfsrudel ist um eine Person gewachsen.

Zwei Wölfe jagen nun zusammen durch die Wüste im Delphi-Land an der Grenze zur WinAPI auf der Suche nach Threads, Speicherlecks und blockierenden Kommunikationsroutinen, deswegen bringe ich heut Morgen einen Toast aus!

:party:

[sh17]

Also es gibt (foren)threads, die haben vorerst auch ohne lösung einen Wert der Unterhaltung ;-)

[Furtbichler]

Zitat:

Zitat von Medium (Beitrag 1208467)

Ich kann Günthers Ansinnen schon gut verstehen. Wir haben auch Software im Einsatz, bei der die aller aller erste Prio ist, dass es LÄUFT.

Ist schon richtig, aber die hemdsärmelige Notlösung ist immer das aller aller aller letzte Mittel. Und vorher sollte man genau(!) wissen, das es nicht anders geht.

Beim schönen Günther bin ich mir derzeit noch nicht sicher, ob er wirklich alle Möglichkeiten ausgereizt hat, schließlich scheint er bei Delphi noch ne ganze Menge lernen zu müssenwollen.

Zitat:

Ein weiterer Thread als Watchdog, die den anderen nach einem Timeout im Zweifel per WinAPI wegballert und neu startet.

So, und wie nun?

Ich habe in einem anderen Thread gewagt, zu behaupten, das ich auf Resourcenschutzblöcke verzichten kann, wenn ich (a) etwas ganz anderes demonstrieren will (z.B. Beispielcode), oder (b) an einer Stelle ganz genau weiß, das das Programm eh beendet wird, wenn's knallt (wozu dann den Speicher freigeben?). Der Thread ging -glaube ich- über 4 Seiten, weil niemand es verstanden hat. In diesem Forum sind von der schönen Norm abweichende Gedankengänge nicht gerne gesehen.

Ebenso sollte man hier gebetsmühlenartig darauf hinweisen, das man das nicht macht, aber wenn schon, dann eben so:... (Du bist am Zug ;-) )

Bei meiner TCP-Anwendung (Maschinenbau, Kommunikation mit MES, Schrottnetzwerk) passiert soetwas auch. Da hilft bei uns dann nur ein Kill-Prozess bzw. die Anwendung schießt sich selbst ab, zur Not wird sie von außen gekillt und wenn das nicht hilft (externe DLL, dieser Schrott), dann wird der Benutzer abgemeldet und durch das Autologin mit Autostart neu gestartet, das dauert eine Sekunde und man merkt das kaum.