Die Frage aller Fragen (Sammlung): „Ist das Thread-Safe?“

[Mavarik]

Zitat:

Zitat von Sir Rufo (Beitrag 1264406)

@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

Delphi-Quellcode:

Inherited Create(false)

schon gestartet? Dann ist der Event noch nicht Created!

Zitat:

Zitat von Sir Rufo (Beitrag 1264406)

Ich würde auch nicht

Delphi-Quellcode:

TThread.Terminate

überschreiben, sondern

Delphi-Quellcode:

Thread.TerminatedSet

, denn das ist schon als

Delphi-Quellcode:

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:

Zitat von Sir Rufo (Beitrag 1264406)

@
Die Klasse selber würde ich noch als

Delphi-Quellcode:

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 :stupid:

Zitat:

Zitat von Sir Rufo (Beitrag 1264406)

@
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

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1264405)

Zitat:

Zitat von Mavarik (Beitrag 1264399)

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?

[Dejan Vu]

Zitat:

Zitat von Sir Rufo (Beitrag 1264406)

...und wenn fangen, dann nur so:

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:

Zitat von Mavarik (Beitrag 1264409)

Und auch nicht für Notebooks?

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

[DeddyH]

Wahrscheinlich verbrauchen sauber behandelte Exceptions zuviel Strom :lol:

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1264411)

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

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

[Der schöne Günther]

Zitat:

Zitat von Dejan Vu (Beitrag 1264411)

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

Das ist eine der wenigen Stellen wo ich Java (Direktive

Delphi-Quellcode:

throws

für Methoden) vermisse. In C# bubbelt auch alles immer weiter nach oben (wie in Delphi), oder?


Aber irgendwie kommen wir vom ursprünglichen Thema ab...

[Dejan Vu]

Zitat:

Zitat von Mavarik (Beitrag 1264422)

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

Ich meinte ja auch nicht dich mit dieser Anmerkung.

Zitat:

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

Das ist eine der wenigen Stellen wo ich Java (Direktive

Delphi-Quellcode:

throws

für Methoden) vermisse. In C# bubbelt auch alles immer weiter nach oben (wie in Delphi), oder?

OT: Ja, wir kommen vom Thema ab, ja, bei C# bubbelt es auch weiter nach oben wie in Delphi und Java und nein, ich vermisse die 'throws' Direktive nicht, denn es ist kein Mehrwert an Übersichtlichkeit und Stabilität (vor allen Dingen nicht: Produktivität).

Meiner Meinung nach kann man über Exceptions mal wieder einen Fred aufmachen. Aber hier ist, dank Günther, dem Schönen, auch von meiner Seite aus Schluss.

[Sir Rufo]

Zitat:

Zitat von Mavarik (Beitrag 1264408)

Zitat:

Zitat von Sir Rufo (Beitrag 1264406)

@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

Delphi-Quellcode:

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

Delphi-Quellcode:

inherited Create( False );

. :)

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 ;)

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;

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1264450)

Der Thread wird erst nach dem kompletten Abarbeiten des Destructors gestartet (das ist absolut gesichert!).

Constructors!

[stoxx]

[QUOTE=Mavarik;1264399]

Zitat:

Zitat von stoxx (Beitrag 1264368)

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.

Dein Ton ist ja gerade noch so freundlich, aber schon recht grenzwertig.
Woher nimmst Du die Behauptung, dass die Klasse intern das sleep nicht mit Waitfor realisiert?
Du kannst ihn doch programmieren, wie Du Lust hast, und den FunctionCall auch erst nach einem einkommenden Event generieren.

Wenn ich aber ständig eine Response brauche, weil ständig Dinge getan/geprüft werden müssen, , dann muss er wohl in der Tat auch ständig bereit sein, um gewisse Dinge zu erledigen.