TThread Suspend und Resume

[dGeek]

Ich mache es immer so:

Delphi-Quellcode:

while not Terminated do
 begin
  if bThreadSollSchlafen then
   Sleep(1000);

  if bThreadBeenden then
   begin
    // Beende den Thread
   end else
    begin
     // Führe Code aus, der ausgeführt werden muss.
    end;
 end;

Soweit ich weis, sind Resume und Suspended doch veraltet.

[stahli]

Ich schließe mich himi an.
Falls Du damit nicht zurecht kommst, kann ich mal etwas zusammenstellen.
Habe das kürzlich auch erstmalig und erfolgreich eingesetzt.

[dGeek]

Das mit dem WaitFor würde mich jetzt aber auch interessieren.
Denn dann wird nicht mehr soviel Energie verbraten als mit den Sleeps.

[himitsu]

Zitat von dGeek:

Soweit ich weis, sind Resume und Suspended doch veraltet.

Nunja, das Einzige, was man niemals machen darf, ist ein Suspend von außerhalb des Threads.
Kein Anderer weiß wo der Thread gerade ist und kann somit den Thread auch nicht "sicher" anhalten.
(sich selber anhalten könnte ein Thread sich schon dürfen, aber da gibt es andere/bessere Wege)

Sicher = nicht an ein "ungünstigen" Stelle

Suspended starten erstellen und dann später starten ist schon noch OK, auch wenn sich die Befehle/Namen von Suspend/Resume vielleicht geändert haben mögen.

Zitat von dGeek:

Das mit dem WaitFor würde mich jetzt aber auch interessieren.
Denn dann wird nicht mehr soviel Energie verbraten als mit den Sleeps.

Sleep macht intern auch "nur" ein WaitFor und wartet auf das TimeOut

Aber es geht sofort weiter (hier muß man immer bis zu 1000 Millisekunden warten, bis es weiter geht)
und der Thread wacht nicht ständig sinnlos zwischendurch auf ... erst, wenn das Event oder der TimeOut ausgelöst haben.

PS: FCancelRequest oder bThreadBeenden sind doch bissl doppelt, vor allem dann, wenn man daran denkt was Terminated schon macht.

[dGeek]

Zitat:

Aber es geht sofort weiter (hier muß man immer bis zu 1000 Millisekunden warten, bis es weiter geht)

Ich warte immer 25ms. Ist schnell genug finde ich.

[Medium]

Da auch bei einem Sleep(1) ein "wartender" Thread zu 0% CPU Auslastung führt, habe ich das bisher immer genommen. Bei mir sehen die Execute-Methoden meist so aus:

Delphi-Quellcode:

procedure TMyThread.Execute;
var
  ...
begin
  while not Terminated do
  begin
    try
      try
        if FWaiting then
          Sleep(1)
        else
        begin
          // Eigentlicher Thread-Code 
          // (setzt ggf. FWaiting selbst auf true wenn die Aufgabe durch ist,
          // da ein Bool aber atomar ist, kann dies auch von aussen passieren)
        end;
      except
        on ...
      end;
    finally
      ...
    end;
  end;
end;

[BUG]

Das Primitiv was du suchst, ist ein Mutex (zB. CriticalSection unter Windows) und eine Condition-Variable. Der Mutex schützt den Zähler (und eventuell andere Datenstrukturen), auf der Condition-Variable kannst du schlafen. Das ist die Standard-Lösung für solche Probleme. So etwas mit Sleep oder Ähnlichem zu implementieren ist Frickelei (Sorry Medium ).
Darauf aufbauend kannst du Warteschlangen implementieren. Dabei schläft der Thread so lange, bis er das nächste Element aus der Warteschlange nehmen kann. Auch so etwas sollte es in Threading-Bibliotheken fertig geben ... da kenne ich mich unter Delphi aber nicht aus.
Nur wenn die Synchronisation ein Flaschenhals ist, muss man nach anderen Lösungen suchen, z.B. nicht-blockierende Algorithmen.

[Blup]

Ich hoffe es wird nicht von außerhalb des Threads auf "Actions" zugegriffen.
Ohne entsprechende Absicherung wäre das ein guter Grund für unerklärliche Fehler und Programmabstürze.

[Mavarik]

Ich hoffe Ihr seit beide auf den Delphitage... Da gibt es einen Vortrag zu diesem Thema...

auf die Schnelle

Delphi-Quellcode:

  while not(Terminated) do
    begin
      try
        FRunning := false; // Atom

        E_Event.WaitFor(FTimeOut);

        if FCancelRequest or Terminated then
          exit;

        FRunning := true;
        // Code der ausgeführt werden soll
      except
      end;
    end;

Mavarik

PS.: Und eine alte Unit für Delphi-User ohne System.Threading oder für Threads die im nano-Sekundenbereiche starten müssen...

Einfache eine eigene Klasse davon ableiten und die abstrakten Proceduren überschreiben...