Zitat von Sir Rufo:

markieren

Delphi-Quellcode:

  with TWorkThread.Create( True, aWorkJob ) do
  begin
    FreeOnTerminate := True;
    Resume;
  end;

Ein Spiel mit dem Feuer. Mit Glück geht sowas gut, aber will man sich darauf verlassen? Nicht umsonst ist Resume mittlerweile als deprecated gekennzeichnet. Zitat aus der Hilfe:

Zitat:

Warnung: Die Methoden Resume und Suspend sollten nur für das Debuggen verwendet werden.

Hintergrund unter anderem:
Wenn der Thread zu schnell fertig ist bevor Resume beendet ist, zieht das FreeOnTerminate dem Code den Boden unter den Füßen weg. Und wenn es nur passiert, weil im Thread eine Exception auftritt, ausschließen kann man so etwas jedenfalls kaum. Dazu gibt es auch umfangreiche Diskussionen, unter anderem auch im Embarcadero Forum unter Beteiligung von deren Entwicklern. Das Fazit ist überall das gleiche: Nie Resume verwenden ist das beste.

Deshalb rate ich stattdessen dringend zu einer sauberen Lösung. Insbesondere hier im Beispiel ist das ja denkbar einfach: Einfach den Thread nicht suspended starten...

Zitat von DelTurbo:

Apprun ist auch Global. Es wird alle 100ms auf 1 gesetzt, über einen normalen TTimer.

Ich frage mich die ganze Zeit wozu das ganze eigentlich global ist. Du kannst dir doch Speicher reservieren, per Message an deinen Hauptthread schicken und der gibt den wieder frei. Dann kannst du dir die ganze zusätzliche Synchronisation sparen.

Und das mit dem Timer kannst du dir dann auch sparen. Denn der Thread kann sich einfach kurz mit Sleep schlafen legen und weitermachen.

Ansonsten gibt es auch noch Events (CreateEvent, SetEvent, ...) um die Signale hin- und herzuschicken. Die sind auch threadsicher.

Zitat von DelTurbo:

Mit der Variante aus dem ersten post, habe ich ein prg gemacht was bis zu 200 threads zeitgleich laufen hat.

Wobei so viele Threads das ganze natürlich sehr stark ausbremsen, wenn die wirklich zeitgleich arbeiten und nicht größtenteils schlafen.

Hi,
also ich weiss nun nicht ob das mit AppRun so eine grosse rolle spielt. Ich habe es einfach in der "unit1" deklariert und fertig. Was soll ich für (theoretisch einem Byte) speicher "hohlen". Find ich bissl umständlich.

Zum Thread. Der soll nicht schlafen, der soll arbeiten. Den gedanken gang kann ich leider nicht nachvollziehen. Ich habe das nun endlich so schnell, das ich mit bis zu 150MBit (im GBitLan) den MySqlServer "anblasen" kann. Und dann soll ich ein sleep einbauen? Sorry, das verstehe ich auch nicht.

Zu den 200 Threads. Das war einmal ein Peak der erreicht wurde. Natürlich Rendern die keine Filme. Normal sind ca. 30-50 Threads, wovon bis zu 10 zeitgleich laufen können (kommt drauf an was er macht). Und selbst die, die "laufen" warten meistens nur rum bis der FTP-Server antwortet.

Danke an alle....

Zitat von jaenicke:

Deshalb rate ich stattdessen dringend zu einer sauberen Lösung. ... Einfach den Thread nicht suspended starten...

Oder FreeOnTerminate nicht verwenden.

Zitat von DelTurbo:

Zum Thread. Der soll nicht schlafen, der soll arbeiten. Den gedanken gang kann ich leider nicht nachvollziehen. Ich habe das nun endlich so schnell, das ich mit bis zu 150MBit (im GBitLan) den MySqlServer "anblasen" kann.

Naja, ich hatte das so verstanden, dass dein Timer den Thread anstößt und der daraufhin Daten in einem globalen Objekt/Record zur Verfügung stellt und wiederum über ein globales Flag signalisiert, dass er fertig ist.

Nein, ich nehme mal die schuld auf mich damit keine weiteren diskusionen aufkommen. Das hauptprob ist ja, das ich schlecht die komplette source hier posten kann. Ich denke mal das würde den Thread sprengen, und nur mehr arbeit machen. Deswegen hatte ich versucht nur die hauptsächlichen sachen zu posten. Ich finde sowas relativ schwer, weil man was vergisst oder weglässt, weil ich selber es ja weiss.

Der Thread ist im grunde eine schleife die "vollgas" einen MySqlServer fillt (mit DirectMysql). Es war schon schwer genug, da einen guten speed zu bekommen. Deswegen der externe timer. Der (Apprun) wird in der schleife abgefragt. Hat er zugeschlagen gebe ich die infos aus. Damit man(n) nicht doof auf eine "Bitte warten" box schauen muss, sondern sieht wo er grade ist.

Allerdings muss ich sagen, seitdem ich Send statt Postmessage nutze, knallt es nichtmehr. Warum das so ist, weiss ich nicht. Zeitlich ist der unterschied nicht messbar.

Ich hatte in der abfrage extra noch "aufgepasst" das Postmessage wirklich zuende ist bevor ich sachen ändere und wieder ein Post schicke. Das habe ich extra gepostet. Daran hatte ich gedacht ^^

Also bei Threads halte ich mich immer an folgende Regeln:
1.) keine Windows-API Funktionen (z.B. BeginThread()) verwenden, sondern immer nur von der TThread-Klasse ableiten.
Der direkte Aufruf von Windows-API Funktionen ist hier viel zu gefährlich und fehlerträchtig.
Warum sich unnötigerweise in Gefahr begeben nur um einige Bytes und Microsekunden zu sparen?

2.) falls viele kleine Aufgaben zu erledigen sind, sollte man einen Threadpool in Betracht ziehen

3.) ein Thread sollte möglichst selbstständig und ohne Kontakt zu anderen Threads ablaufen.
Das bedeutet insbesondere: nicht auf globale Variablen zugreifen (ausser es geht nicht anderst).
Natürlich auch keine Funktionen aufrufen, die mit globalen Daten arbeiten.
Das Thread-Objekt bekommt alle nötigen Daten von Aussen über Properties übergeben und arbeitet dann mit seiner lokalen Kopie.
Die Ergebnisse des Threads werden über Properties zurückgegeben.
Man könnte die Thread-Klasse also unverändert ausschneiden und in ein anderes Programm einfügen, weil sämtliche Abhängigkeiten über Properties der Klasse bedient werden.
Das Prinzip ist EVA: Eingabe - Verarbeitung - Ausgabe

4.) Kommunikation mit der VCL vermeiden bzw. so gering wie möglich halten

5.) Innerhalb der Execute-Methode sollte man immer wieder das Property Terminated abfragen (Falls True, Thread sofort beenden)
Fragt man Terminated zu häufig ab, bremst das den Thread, fragt man zu selten oder gar nicht ab, behindert das das Verhalten (z.B. beim Herunterfahren von Windows).

6.) Exceptions innerhalb des Threads abfangen (andernfalls gehen sie verloren)

zusammenfalten · markieren

Delphi-Quellcode:

procedure TMyThread.Execute;
begin
  try
    InternalExecute;
    ReturnValue := 0;
  except
    on E:Exception do
    begin
      OutputDebugString(PChar(E.Message));
      ReturnValue := -1;
      self.ExceptMessage := E.Message; // Meldung für später in einem Property merken
    end;
end;

Besonders Punkt 3. ist in der Praxis nicht so einfach und kann auch je nach Aufgabe nicht immer so erfolgen.
Aber die Probleme werden merklich reduziert.