Polling im TThread

[haentschman]

Hallo alle...

Die "Anweisungen" sollen im Thread aller z.B. 10 Sekunden ausgeführt werden. Ein beherztes Sleep im Execute hat die gleiche Auswirkung. Nur wenn der Thread von Außen terminated wird dauert es ebenfalls 10 Sekunden bis zum Beenden was nicht gewünscht ist.

...ein Timer ist keine gute Wahl.

PS: Diese "Aufgabe" habe ich zum ersten Mal.

Lösungsvorschläge? (mal sehen ob ihr bessere habt )

Ergänzung zu http://www.delphipraxis.net/72265-th...eleganter.html

[Sir Rufo]

Ein Event vielleicht, wo man 10 Sekunden wartet ob er auslöst und wenn nicht, dann die Aktion ausführt?

[Namenloser]

Das entspricht ja der 2. Variante aus dem verlinkten Beitrag. Ich halte das auch für die richtige Lösung.

[haentschman]

Danke für deine Antwort. Event...wie meinst du das?

mein Vorschlag:

Delphi-Quellcode:

procedure TWorkerPolling.Execute;
var
  StartCount: Cardinal;
  CurrentCount: Cardinal;
begin
  inherited;
  StartCount:= 0;
  while not Terminated do
  begin
    CurrentCount:= GetTickCount;
    if (CurrentCount - StartCount) > conPollingInterval then // conPollingInterval = 10000
    begin
 
     // auszuführender Code

      StartCount:= CetTickCount;
    end;
    Sleep(100); // für Leerlauf
  end;
end;

...auf die 100 ms "Versatz" kann man verzichten.

Zitat:

wo man 10 Sekunden wartet ob er auslöst

...das Warten ist ja das Problem. Auf der einen Seite sollen die Anweisungen nur alle X Milisekunden ausgeführt werden, auf der anderen Seite soll der Thread von Außen sofort beendbar sein. Ist der Thread gerade in der "Verarbeitung" macht er diese natürlich erst fertig und beendet sich dann sofort weil Terminated von außen gesetzt wurde.

[Namenloser]

Zitat von haentschman:

Event...wie meinst du das?

TEvent

Deine Variante geht natürlich auch, ist aber im Grunde busy-waiting und daher unschöner.

[haentschman]

ok...das nächste Mal drücke ich mich geschickter aus. Events benutzte ich reichlich weil ich weis wie es geht... Nur im Zusammenhang mit Thread und Auslösen / Warten stand ich auf dem Schlauch...

[Uwe Raabe]

Den Event beim Terminate auslösen geht am elegantesten, wenn man DoTerminate überschreibt.

[haentschman]

Zitat:

ist aber im Grunde busy-waiting und daher unschöner.

Der Thread soll ja nur den Codeblock abarbeiten... aber nur alle 10 Sekunden. Den Rest macht er nur im Execute die Schleife. (Leerlauf) Warum ist das unschön? Ein Thread läuft doch sowieso im Execute im Kreis und macht immer das Gleiche.

Zitat:

Den Event beim Terminate auslösen geht am elegantesten, wenn man DoTerminate überschreibt.

Vieleicht ist es ja schon zu spät...Aber ich verstehe nicht wie mir ein Event im überschriebenen DoTerminate beim normalen Abarbeiten im Execute hilft.

[Namenloser]

Zitat von haentschman:

Zitat:

ist aber im Grunde busy-waiting und daher unschöner.

Der Tread soll ja nur den Codeblock abarbeiten... aber nur alle 10 Sekunden. Den Rest macht er nur im Execute die Schleife. (Leerlauf) Warum ist das unschön? Ein Thread läuft doch sowieso im Execute im Kreis und macht immer das Gleiche.

Weil der Thread alle 100ms aufgeweckt wird statt alle 10 Sekunden. Jedes Aufwecken verbrät etwas CPU-Zeit. Dazu kommt noch als weiterer Nachteil die 100ms-Latenz beim Beenden. Letztlich kannst du hier stufenlos zwischen zwei Übeln wählen: kleinere Warteintervalle und damit kleinere Latenz aber dafür höhere CPU-Verschwendung, oder höhere Warteintervalle und damit weniger CPU-Verschwendung aber dafür größere Latenz.

Beides ist aber völlig unnötig, weil das Betriebssystem in Form von Events bereits eine perfekte Lösung anbietet.

[himitsu]

Das einfachste und beste Beispiel, für das eben Genannte, ist die Delay-Funktion von Hagen.

• möglichst wenig CPU-Last, da nichts gemacht wird, ohne daß etwas ansteht
• und wenn etwas ansteht, oder wenn die Zeit abgelaufen ist, dann wird sofort reagiert