Fragen zum TThread, Programm absturzsicher?

[BAMatze]

Hallo @ all,

Ich hab einige Fragen zu der Komponente TThread. Ich möchte für ein Projekt, bei dem wichtige Daten erzeugt werden, soll Absturz sicher gemacht werden. Dazu möchte ich das Programm wie folgt aufbauen:

Der durch den Start erzeugte Thread soll als so eine Art Sicherheitsthread dienen, der rein nur die Daten für mich sichert, die erzeugt werden. Damit möchte ich verhindern (was bei uns schonmal in der Firma passiert ist, dass nach 2h Computerarbeitszeit und einem Programmabsturz sämtliche Daten verloren gehen). Dieser Sicherheitsthread soll den eigentlichen Arbeitsthread erzeugen und in dem wird eigentlich sämtliche Arbeit erledigt.

Jetzt meine Frage: Wenn ich eine Exception in dem Arbeitsthread bekomme, führt das auch zu einem kompletten Programmabsturz oder wird dann nur der Arbeitsthread tot gemacht oder führt es auch zu einem kompletten Programmabsturz? Wenn es einen kompletten Programmabsturz gibt, kann man dies auf irgendeine Art verhindern, so dass der Sicherheitsthread weiterlaufen kann?

Vielen Dank
BAMatze

[sirius]

Ein kompletter Programmabsturz entsteht wenn im Hauptthread (dort, wo das Programm startet) eine Exception nicht mit try..Except abgefangen wird. Wird ein einem Kindthread eine Excepütion nicht abgefangen beendet das nur diesen Thread.

Ich glaube du solltest dir eher Gedanken über Exceptionbehandlung machen und dann über Threads nachdenken.

[BAMatze]

Zitat:

Zitat von sirius

Ein kompletter Programmabsturz entsteht wenn im Hauptthread (dort, wo das Programm startet) eine Exception nicht mit try..Except abgefangen wird. Wird ein einem Kindthread eine Excepütion nicht abgefangen beendet das nur diesen Thread.

Ich glaube du solltest dir eher Gedanken über Exceptionbehandlung machen und dann über Threads nachdenken.

Also da ich hier ja eher "Learning by Doing" mache, bin ich für solche Hinweise sehr dankbar. Das mit Try..Except habe ich auch schon in dem Programm verwendet. Glaube ich erkläre mal etwas mehr. Also das Programm steuert eine Produktionsanlage. Das heißt es sind etliche Perepherie-Geräte dran und die Kamera, welche mir gegeben wurde, die Bilder im Micrometer-Bereich macht, kann nicht in Delphi programmiert werden, da die Eigenschaften der Komponenten in Delphi nicht konform mit den Definitionen für die Kamera gehen. Das Hauptproblem ist dabei die Live-Kameradarstellung auf dem Monitor. Deswegen verwende ich eine ActiveX-Komponente von der Firma, die die Kamera herstellt. Diese scheint nur etwas lieblos programmiert (Fehlermeldungen komme teilweise 2mal und seit Einbindung der Komponente kommt es vermehrt dazu, dass sich das Programm nicht vollständig schließen lässt -> Computer muss neu gestartet werden, damit das Programm wieder lauffähig wird) zu sein, was zu ständigen Querschlägern in dem Programm führt. Da ich derzeit nicht die Kenntnisse habe um die ActiveX-Komponente neu in einer anderen Sprache zu schreiben, die ich auch noch nicht kann, möchte ich das Problem erstmal (gewissen Zeitdruck hab ich ja auch, wegen Termin) auf die Weise lösen, dass ich den Thread in einem Nebenthread packe und somit die Daten sichern kann und darauf zielte die Frage an sich hin.

Danke dir für die schnelle Antwort @ sirius.

[messie]

Ist bei der Kamera vielleicht eine dll dabei, mit der Du aus Delphi zugreifen kannst? Mit ActivX-Controls ist das so eine Sache...

Grüße, Messie

[sirius]

Mir fällt dazu nicht viel ein. Wenn sogar der ganze Computer abstürzt. Da muss ja einiges falsch sein. Das sieht ja schon mehr nach Treiberproblemen aus.

Und sichtbare Controls sollte man immer im Hauptthread lassen, deswegen sehe ich keine Chance das ActiveX-Control in einen anderen Thread zu legen.

[BAMatze]

Zitat:

Zitat von messie

Ist bei der Kamera vielleicht eine dll dabei, mit der Du aus Delphi zugreifen kannst? Mit ActivX-Controls ist das so eine Sache...

Grüße, Messie

Ja eine Dll ist dabei. Mit der konnte ich auch alles realisieren in Delphi, bis auf die Darstellung der Live-Video-Funktion, dafür fehlt den Delphi-Komponenten, so wie ich das in den Manuels gelesen hab die richtige Darstellungsmöglichkeit, die wohl in C++ und VB vorhanden sind, was ich aber nicht ganz verstehen kann, da ja auch die TForm die Eigenschaft Canvas meiner Meinung nach hat. Aber auch der Versuch das Live-Kamerabild in ein Bmp und dann TPaintbox oder Image zu packen sowie direkte Ausgabe auf ein Panel (Canvas) scheiterte. Die einzige Möglichkeit nach Beschreibung der Herstellerfirma für Delphi ist erstmal die Verwendung der ActiveX-Komponente.

@ sirius also der gesamte Rechner stürzt nicht ab, das hab ich in der Entwicklungszeit eigentlich gut unter Kontrolle bekommen, ist allerdings nachher, wenn ich (wegen Firmenblindheit für die eigene Arbeit) später nicht mehr selber dran sitze, nicht ausgeschlossen, dass es nochmal passiert. Aber was derzeit immer wieder passiert, sind Exceptions (trotz try und except) und damit verbundene Datenverluste. Dies möchte ich mit der Methode eigentlich minimieren. (Lasse derzeit schon mehrere Sicherungen mitlaufen z.B. erstellen einer Tempfile und protokollieren in dieser).

BAMatze

[himitsu]

Wenn es in Delphi angeblich nicht geht, dann könntest du dir eventuell eine DLL in C oder VB erstellen, welche auf die Kamera zugreift und dein Delphi-Programm greift über diese DLL zu.

die Möglichkein die Kamera in einem extra Programm laufen zu lassen bestünde auch noch ... beide Programme könnten dann via IPC (MMF / Messages) miteinander kommunizieren.

[BAMatze]

Zitat:

Zitat von himitsu

Wenn es in Delphi angeblich nicht geht, dann könntest du dir eventuell eine DLL in C oder VB erstellen, welche auf die Kamera zugreift und dein Delphi-Programm greift über diese DLL zu.

die Möglichkein die Kamera in einem extra Programm laufen zu lassen bestünde auch noch ... beide Programme könnten dann via IPC (MMF / Messages) miteinander kommunizieren.

Also ich will im Frühjahr/ Sommer das Programm nochmal überarbeiten. Das heißt gerade arbeite ich eh an einer Art Beta-Version, die aber einen terminierten Abgabetermin hat. Danach soll ich dies eh überarbeiten und da habe ich auch schon über solche Möglichkeiten nachgedacht, wobei die Variante eine eigene ActiveX-Komponente in C# zu schreiben derzeit die favourisierte ist, da ich einen Kollegen hab, der die Sprache gut kann, aber leider keine Zeit hat mir die Komponente zu erstellen. Das heißt einarbeiten in C# und dann kann ich nach Hilfe fragen, wenn ich mal ein Problem hab.

Was ich an deiner Lösung nicht verstanden hab ist, wie mein Problem mit einer DLL in C oder VB gelöst wird, vieleicht kannst du da noch etwas genauer werden. Denn das Problem, dass die Delphi-Komponenten anscheinend nicht die geeignete Schnittstelle haben, um das Live-Bild der Kamera darzustellen bleibt doch oder hab ich da jetzt einen Denk-Fehler?

BAMatze

[sirius]

Warum sollte das Delphi nicht anzeigen können?

[Sunlight7]

Zitat:

Zitat von sirius

Wird ein einem Kindthread eine Excepütion nicht abgefangen beendet das nur diesen Thread.

Sicher?
Zumindest in ältere Delphis stürtzt das Programm ab.

[BAMatze]

Zitat:

Zitat von sirius

Warum sollte das Delphi nicht anzeigen können?

Hier ein kurzer auszug aus dem Programmierhandbuch.

[himitsu]

Zitat:

Zitat von BAMatze

wie mein Problem mit einer DLL in C oder VB gelöst wird,

Na wenn es angeblich in Delphi nicht Möglich ist, dann einfach in einer der anderen Sprachen, mit denen es geht, drauf zugreifen.

Also dein Delphiprogramm sagt z.B. der in C geschriebenen DLL was es haben möchte, diese holt beispielsweise das Bild, wandelt es notfalls in ein für Delphi verständliches Format um und gibt es dann an dein Programm weiter.

Aber vermutlich am Besten wäre es rauszufinden warum das nicht direkt in Delphi gehen soll und den Zugriff womöglich doch noch hinzubekommen.

[sirius]

Also da steht, man sollte es nicht in Delphi programmieren, weil:
"Es müssen eigene Header Dateien erstellt werden."
Ist ja schön, dass auf das ActiveX-Control verwiesen wird, aber wenn das fehlerhaft ist, muss man eben ein Schritt zurück gehen.

Also wenn das diese Community hier nicht schafft.... Wie sehen denn die C-Header aus?

[BAMatze]

Zitat:

Zitat von sirius

Also da steht, man sollte es nicht in Delphi programmieren, weil:
"Es müssen eigene Header Dateien erstellt werden."
Ist ja schön, dass auf das ActiveX-Control verwiesen wird, aber wenn das fehlerhaft ist, muss man eben ein Schritt zurück gehen.

Also wenn das diese Community hier nicht schafft.... Wie sehen denn die C-Header aus?

Also die Header sind ziemlich unübersichtlich, da hat sich ein ausgebildeter Informatiker mal richtig ausgetobt. Konnte zwar einige Daten entnehmen, aber für jemanden, der nicht versiert in C/C++ ist, leider unmöglich dort wirklich alles zu verstehen.

[nahpets]

Hallo,

schau mal bitte bei Dr. Bob nach:
http://www.drbob42.com/headconv/index.htm
Auf der Seite bekommst Du ein Tool, das aus C-Headerdateien Pascal/Delphi-Units macht. Eventuell reicht das ja schon für Deine Aufgabe.

[BAMatze]

Hmm bin jetzt irritiert, da bei einem Versuch auch der Hauptthread gecrasht ist, obwohl eine Exception nur im Nebenthread aufgetreten ist. Also gehe ich jetzt mal davon aus, dass dies wie meine erste Frage implizierte wohl doch nicht funktioniert. Oder mache ich da etwas falsch oder habe ich was übersehen?

[Sunlight7]

Zitat:

Zitat von Sunlight7

Zitat:

Zitat von sirius

Wird ein einem Kindthread eine Excepütion nicht abgefangen beendet das nur diesen Thread.

Sicher?
Zumindest in ältere Delphis stürtzt das Programm ab.

...



Versuchs mit try-except in Deinem Thread die Exceptions abzufangen, das läßt Deine Anwendung am Leben ;)

[himitsu]

Zitat:

Zitat von Sunlight7

Sicher?
Zumindest in ältere Delphis stürtzt das Programm ab.

ich weiß jetzt nicht wie's früher war, aber TThread schließt .Execute in einen Try-Except-Block ein (und das dann witziger Weise nochmal in 'nen Try-Finally) ... vielleicht hängt das ja damit zusammen.

[Sunlight7]

Hab mal eben getestet:

D2: Fehlermeldung, Programm beendet
D5: Programm beendet sich ohne Fehlermeldung :shock:
BDS 10: Nix tut sich


@TE: Einfach mal in nem neuem Projekt testen, was Dein Delphi so an Verhalten compiliert.

Edit: Find ich schon witzig, das in zB BDS 10 die Exception einfach so per Standard verschluckt werden..

[himitsu]

in D7 dürfte es auch nicht abstürzen

und so einfach verschlugt wird die Exception nicht wirklich

{} ist in D2009 drin und gab's in D7 noch nicht

Delphi-Quellcode:

function ThreadProc(Thread: TThread): Integer;
var
  FreeThread: Boolean;
begin
  {}InternalCurrentThread := Thread;
  {}if Thread.FSuspended then sem_wait(Thread.FCreateSuspendedSem);
  try
    if not Thread.Terminated then
    try
      Thread.Execute;
    except
      Thread.FFatalException := AcquireExceptionObject;
    end;
  finally
    FreeThread := Thread.FFreeOnTerminate;
    Result := Thread.FReturnValue;
    Thread.DoTerminate;
    Thread.FFinished := True;
    SignalSyncEvent;
    if FreeThread then Thread.Free;
    EndThread(Result);
  end;
end;

[sirius]

Ok, ich habe es mal getestet (in D7)

• Direkt über die WinAPI bleibt das komplette Programm stehen (tut nix mehr aber schließt sich auch nicht), wenn in einem Thread eine Exception auftritt:
  
  Delphi-Quellcode:

  function ThreadFunc(lparam:Integer):Integer; stdcall;
  begin
    raiseException(0,0,0,nil);
  end;
  
  procedure TForm1.Button2Click(Sender: TObject);
  var temp:Cardinal;
  begin
    createthread(nil,0,@ThreadFunc,nil,0,temp);
  end;

• Bei BeginThread legt Delphi noch ein Exceptionframe auf die Funktion _ExceptionHandler der eine schöne Meldung ausgibt und dann das Programm beendet
• TThread hat (was mir in Erinnerung war und wie himitsu sagt) ein try..except um die Methode Execute. Die Exception wird dann in der Eigenschaft FatalException gespeichert und kann abgerufen werden. Egal was gemacht wird, der Thread beendet sich und alles andere läuft normal weiter. Kein Meldungsfenster, kein nix.

[BAMatze]

@ sirius,

also erstmal danke für deine Mühen, aber kannst du da nochmal etwas genauer drauf eingehen? Ich hab das nicht wirklich verstanden, wie ich das Hauptthread absturzsicher mache. Könntest das eventuell nochmal etwas genauer erklären? also bei meinem Rad Studio 2006 ist bisher immer beide Threads durchgebrannt bei einer Exception. Hab noch keinen Weg gefunden, wie ich das verhindern kann. Dies scheint dir ja gelungen zu sein.

Auch Danke an euch andere.
BAMatze

[himitsu]

nunja, am einfachsten scheint es zu sein, wenn du alle Hauptprozeduren deiner Thread und des Hauptthreads in Try Except verpackst.

[BAMatze]

Zitat:

Zitat von himitsu

nunja, am einfachsten scheint es zu sein, wenn du alle Hauptprozeduren deiner Thread und des Hauptthreads in Try Except verpackst.

Ja dies scheint auch seine Vorteile zu haben, da man dann in den Except-Teil gleich eine Fehlermeldung übergeben kann, aber würde gern mal wissen, wie Sirius das gemacht hat. Hat auch einen Hintergrund, ein großes Programm meines Vorgängers, hat trotz try und Except regelmäßige Abstürze und sämtliche Daten gehen verloren (habe ich im Einleitungsteil dieses Threats schonmal beschrieben). Möchte dies bei meinem Programm vermeiden. Deswegen möchte ich das mal nachvollziehen, was sirius da gemacht hat, damit ich mir die beste Variante oder eine Kombination machen kann.

[himitsu]

siehe Beitrag #20, da bemerkt man, daß Delphi bei TThread die Thread-Prozedur (.Execute) schon mit einem Try-Except-Block absichert (zumindestens in "neueren" Delphiversionen)

k.A. ob's funktioniert

Delphi-Quellcode:

Program MyProgram;

Uses SysUtils, Forms, Unit1;

Var doRestart: Boolean;

Begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Repeat
    doRestart := False;
    Try
      Application.Run;
    Except
      doRestart := True;
    End;
  Until doRestart and not Application.Terminated;
End.

hier hab ich mal alles verpackt und versucht die Finalisierung von Application nachzubauen:

Delphi-Quellcode:

Uses SysUtils, Classes, Forms, Unit1;

Function FindGlobalComponent(Const Name: String): TComponent;
  Var i: Integer;

  Begin
    For i := 0 to Screen.FormCount - 1 do Begin
      Result := Screen.Forms[i];
      If not (csInline in Result.ComponentState) and
          (CompareText(Name, Result.Name) = 0) Then Exit;
    End;
    For i := 0 to Screen.DataModuleCount - 1 do Begin
      Result := Screen.DataModules[i];
      If CompareText(Name, Result.Name) = 0 Then Exit;
    End;
    Result := nil;
  End;

Var doRestart: Boolean;

Begin
  Repeat
    doRestart := False;
    Try
      Application.Initialize;
      Application.CreateForm(TForm1, Form1);
      Application.Run;
    Except
      doRestart := True;
      Try
        If (Application <> nil) and (Application.Handle <> 0) Then Begin
          Application.Minimize;
          Application.ShowHint := False;
          Application.Destroying;
          Application.DestroyComponents;
        End;
        // If HintDoneEvent <> 0 Then CloseHandle(HintDoneEvent);
        UnregisterFindGlobalComponentProc(FindGlobalComponent);
      Except
      End;
    End;
  Until doRestart and not Application.Terminated;
End.

aber eigentlich die die Nachrichtenbearbeitung des Hauptthreads (im .Run) auch per Try-Except abgesichert.