Zitat von stoxx:

Bei mir gibt es eine Klasse "TThreadExecuter" .. die bekommt einfach einen MethodenPointer und ruft zyklisch wie ein Timer einen MethodenPointer der gewünschten Klasseauf. Meist 1 ms mit Sleep(1) .. aber oft ist das gar nicht notwendig.

Autsch...

Ich würde die Klasse nicht ThreadExecuter, sondern lieber "TSaugdenAkkuleer" oder "TCPUCycleKiller" nennen...

Dafür gibt es doch Waitfor oder Multisyncwait damit der Thread schläft so lange er nicht gebraucht wird.

Mavarik

PS.: Ich habe mir hierfür eine mini Unit gemacht die so was erledigt.

zusammenfalten · markieren

Delphi-Quellcode:

unit UseMyThread;

interface

Uses System.Classes,System.SysUtils,System.SyncObjs,System.Generics.Collections;

type
  TMyThread = class(TThread)
   Private
      FRunning : boolean;
      E_Event : TEvent;
   Protected
      Procedure Execute;override;
   Public
      Constructor Create;
      Destructor Destroy;override;
      procedure Terminate; reintroduce; virtual;
      Procedure MyExecute;Virtual;Abstract;
      Procedure MyFree;Virtual;Abstract;
      Procedure Go;
  end;

  // ProcessorCount


implementation

{ TMyThread }

constructor TMyThread.Create;
begin
  inherited Create(true);

  E_Event := TEvent.Create(NIL,false,false,'');
  FRunning := false;

  FreeOnTerminate := false;
end;

destructor TMyThread.Destroy;
begin
  Terminate;

  inherited;

  try
    MyFree;
  except
  end;

  try
    E_Event.Free;
  except
  end;
end;

procedure TMyThread.Execute;
begin
  while not(Terminated) do
    begin
      try
        FRunning := false; // Atom ?

        E_Event.WaitFor(INFINITE);

        if Terminated then
          exit;

        FRunning := true;
        MyExecute;
      except
      end;
    end;
end;

procedure TMyThread.Go;
begin
  if not(Started) then
    Start;

  E_Event.SetEvent;
end;

procedure TMyThread.Terminate;
begin
  inherited Terminate;
  E_Event.SetEvent;
end;


end.

Zitat von Mavarik:

Ich würde die Klasse nicht ThreadExecuter, sondern lieber "TSaugdenAkkuleer" oder "TCPUCycleKiller" nennen...

Nicht jeder Entwickelt für akkubetriebene Küchenschneidbretter.

Eine Frage zu deinem Code: Hast Du schon mal was von Fail Fast gehört, oder einfach ausgedrückt: "Ordentliches Exception Handling"? Dein "An die Wand gefahren? Merkt doch keiner" ist eventuell schwierig beim Finden von Fehlern.

Noch eine Frage: Wo ist der Mehrwert der Methode 'Go' ggü 'Resume'? Klar, der Aufruf von 'Suspend' ist ein No-Go, aber ansonsten?

Zitat von Dejan Vu:

Zitat von Mavarik:

Ich würde die Klasse nicht ThreadExecuter, sondern lieber "TSaugdenAkkuleer" oder "TCPUCycleKiller" nennen...

Nicht jeder Entwickelt für akkubetriebene Küchenschneidbretter.

Und auch nicht für Notebooks?

Zitat von Mavarik:

Zitat von Dejan Vu:

Zitat von Mavarik:

Ich würde die Klasse nicht ThreadExecuter, sondern lieber "TSaugdenAkkuleer" oder "TCPUCycleKiller" nennen...

Nicht jeder Entwickelt für akkubetriebene Küchenschneidbretter.

Und auch nicht für Notebooks?

Komischerweise, selbst wenn man so vorgehen muss, weil es das Konzept nicht anders erlaubt, erzeugt ein Thread mit Sleep(1) in einer Schleife NULL CPU Last .. woher nimmst Du die Behauptung, dass eine CPU mit Null Last strom verbrauchen würde?
Nichtmal der Lüfter springt an..

@Frank

Den Thread im Suspended-Mode zu starten macht irgendwie keinen Sinn, da der doch schon durch den Event wartet.

Ich würde auch nicht TThread.Terminate überschreiben, sondern Tthread.TerminatedSet , denn das ist schon als virtual deklariert und somit zum Überschreiben gedacht.

Die Klasse selber würde ich noch als abstract deklarieren (nur wegen der Dokumentation), denn ohne Ableitung ist die ja so nicht lauffähig.

Einfach so die Exception wegfangen ist auch nicht gerade schön, und wenn fangen, dann nur so:

markieren

Delphi-Quellcode:

try
  MyExecute;
except
  // Nur spezielle Exceptions fangen, die MyExecute bewusst ausgelöst hat
  // Alle anderen unvorhergesehenen werden durchgereicht
  on E:MyExecuteException do
    begin
    end;
end;

Das hier

markieren

Delphi-Quellcode:

try
  E_Event.Free;
except
end;

ist auch unsauber. Wenn meine Klasse nicht funktioniert, dann möchte ich die Fehler um die Ohren geschlagen bekommen.

Bei dem MyExecute und MyFree sieht das etwas anders aus, da hierfür nicht die Klasse TMyThread zuständig ist.

Aber was passiert denn, wenn in MyExecute ein übler Fehler passiert (StackOverflow)?
Der Code kann immer wieder ausgeführt werden, ohne jeden Hinweis auf den Fehler.

Das Terminate im Destructor ist überflüssig (wird schon implizit vom inherited aufgerufen ... ach nee, bei dir ja nicht )

Zitat von Sir Rufo:

@Frank
Den Thread im Suspended-Mode zu starten macht irgendwie keinen Sinn, da der doch schon durch den Event wartet.

Sicher? Wird der Thread nicht bei Inherited Create(false) schon gestartet? Dann ist der Event noch nicht Created!

Zitat von Sir Rufo:

Ich würde auch nicht TThread.Terminate überschreiben, sondern Thread.TerminatedSet , denn das ist schon als virtual deklariert und somit zum Überschreiben gedacht.

Wenn Du eine Delphi Version hast die diese Implementierung schon hat, gebe ich dir Recht. D2007 hat das noch nicht.

Zitat von Sir Rufo:

@
Die Klasse selber würde ich noch als abstract deklarieren (nur wegen der Dokumentation), denn ohne Ableitung ist die ja so nicht lauffähig.

OK.. Kann man machen... Obwohl der Compiler das auch so meldet.. Aber Du hast recht... Bin neu im "Abstract" Bereicht

Zitat von Sir Rufo:

@
Einfach so die Exception wegfangen ist auch nicht gerade schön

Das ist Teil unseres "Unser Programm hat keine Exceptions" Konzept... Bitte hierzu keine Diskussion anfangen, Danke...

Mavarik

Zitat von Mavarik:

Zitat von Sir Rufo:

@Frank
Den Thread im Suspended-Mode zu starten macht irgendwie keinen Sinn, da der doch schon durch den Event wartet.

Sicher? Wird der Thread nicht bei Inherited Create(false) schon gestartet? Dann ist der Event noch nicht Created!

Nein, definitiv nicht!

PS
Wenn du so eine Angst davor hast, dann leg die Erzeugung des Events einfach vor das inherited Create( False ); .

markieren

Delphi-Quellcode:

constructor TMyThread.Create;
begin
  E_Event := TEvent.Create(NIL,false,false,'');
  FRunning := false;

  inherited Create( False ); // nein, nicht schlafen :)

  FreeOnTerminate := false;
end;

Der Thread wird erst nach dem kompletten Abarbeiten des Destructors Constructors (Danke an Uwe) gestartet (das ist absolut gesichert!). Und das auch nicht direkt sofort, sondern auch erst nach einer gewissen Dauer, weil der Thread erstmal warten muss, bis er an der Reihe ist.

Führe einfach mal dieses hier aus und wundere Dich

zusammenfalten · markieren

Delphi-Quellcode:

type
  TMyThread = class( TThread )
  protected
    procedure Execute; override;
  end;

procedure TMyThread.Execute;
begin
  inherited;
end;

procedure ThreadTest;
var
  LThread : TThread;
  LCount : Int64;
begin
  LCount := 0;
  LThread := TMyThread.Create( False );
  try
    while not LThread.Started do
      Inc( LCount );
  finally
    LThread.Free;
  end;
  Writeln( 'Gestartet nach ', LCount, ' Loops' );
end;

Zitat von Sir Rufo:

...und wenn fangen, dann nur so:

markieren

Delphi-Quellcode:

try
  MyExecute;
except
  // Nur spezielle Exceptions fangen, die MyExecute bewusst ausgelöst hat
  // Alle anderen unvorhergesehenen werden durchgereicht
  on E:MyExecuteException do
    begin
    end;
end;

Hmm... Kommentarlos? Noch nicht mal loggen? Gewagt, gewagt. Würde ich nie nicht niemals so machen. Wenn es eine Exception als Flusskontrolle gibt, dann muss das im 'MyExecute' abgefangen werden. Diese Methode hat sorge zu tragen, das sie sauber terminiert, bzw. kontrolliert Exceptions weiterleitet. Dann muss aber in der aufrufenden Methode eine vollständige Exceptionbehandlung erfolgen, meinst Du nicht?

Zitat von Mavarik:

Und auch nicht für Notebooks?

Nö. Nur für Industrieboliden. Aber mal im Ernst: Du hast Recht. Stromsparen tut nicht weh und ist auch nicht verkehrt.

Wahrscheinlich verbrauchen sauber behandelte Exceptions zuviel Strom

Zitat von Dejan Vu:

Hmm... Kommentarlos? Noch nicht mal loggen? Gewagt, gewagt.

Das hab ich nicht gesagt... Ich wollte Euch nicht mir meinem "Restsource" verwirren...