CPU Fresser beim Warten auf ein Flag - Lösung ?

[moelski]

Moin !

Ich habe da ein Problem und hoffe mal das mir jemand weiterhelfen kann.
Und zwar habe ich irgendwo (ich glaube hier im Forum) mal ne Procedur gefunden, die auf ein Flag wartet. Die schaut so:

Delphi-Quellcode:

procedure WaitForFlag(Flag : PBoolean ; TimeOutSeconds : integer = 10);
var EndTime : Extended;
begin
  Flag^   := True;
  EndTime := Now() + TimeOutSeconds * OneSecond;

  while (Flag^ = True) and (Now() < EndTime) do
    Application.ProcessMessages;
  //if Flag^ then raise ETimeOut.Create;
end;

Das funktioniert auch alles prima. Nur die CPU Last steigt beim warten in ganz ungünstige Höhen. Teilweise bis 99% und dabei ist es auch fast egal, wie schnell der Rechner ist.

Frage also ... Hat jemand eine Procedure, die solange wartet bis ein Flag gesetzt ist? Andere Programmteile sollte natürlich im Hintergrund nicht geblockt werden.
Und ja ich brauche so eine Funktion, weil ich immer auf einen Bestimmten Zustand warten muss. Geht leider nicht anders.

Wäre für einen Tip Dankbar :)

Anbei noch ein kleines Demoprojekt was das Prob zeigt ...

Greetz Dominik

[Bernhard Geyer]

Die einfachste Anpassung:

Delphi-Quellcode:

  while (Flag^ = True) and (Now() < EndTime) do
  begin
    Sleep(1);
    Application.ProcessMessages; 
  end;

[moelski]

Moin Bernhard !

Hmm, so recht funzt das aber ned.
Man kann die Anwendung fast nimmer schliessen wenn man den Code nutzt.
Und scheinbar tut es damit auch nicht richtig.

Ich habe mal eine neue Demo angehängt.
Das Label wird nie neu gesetzt !? Bedeutet für mich er wartet nicht richtig oder kommt nie aus der Schleife raus.
Hast du evtl. noch einen Tip ?

Greetz Dominik

[Luckie]

Warum übergibst du denn um Gottes Willen einen Boolean Zeiger? Und warum übergibst du deiner Prozedur das ChekcBox Objekt? Was soll die damit anfangen? Bitte mal etwas selber nachdenken. Flag muss ausserdem global sein, wie willst du es sonst setzen, wenn er in der Schleife ist?

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    CheckBox1: TCheckBox;
    Label1: TLabel;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
    procedure FormClose(Sender: TObject; var Action: TCloseAction);
    procedure CheckBox1Click(Sender: TObject);
  private
    { Private-Deklarationen }
    Flag: Boolean;
    procedure WaitForFlag(TimeOutSeconds: DWORD = 10);
  public
    { Public-Deklarationen }
  end;

var
  Form1             : TForm1;

implementation

{$R *.dfm}

procedure TForm1.WaitForFlag(TimeOutSeconds: DWORD = 10);
var
  EndTime           : DWORD;
begin
  Flag := True;
  EndTime := GetTickCount + TimeOutSeconds * 1000;

  while (Flag = True) and (GetTickCount < EndTime) do
  begin
    Sleep(1);
    Application.ProcessMessages;
  end;

end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  Flag := True;
  WaitForFlag;
  Label1.Caption := 'Done ...';
end;

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  Flag := False;
end;

procedure TForm1.CheckBox1Click(Sender: TObject);
begin
  Flag := not CheckBox1.Checked;
end;

[Christian Seehase]

Moin Michael,

Zitat:

Zitat von Luckie

Flag muss ausserdem global sein, wie willst du es sonst setzen, wenn er in der Schleife ist?

nein, denn das

Zitat:

Zitat von Luckie

Warum übergibst du denn um Gottes Willen einen Boolean Zeiger?

macht's möglich ;-)

[alzaimar]

Man darf sich nicht wundern, wenn die Anwendung im Taskmanager bei 100% steht, denn schließlich macht sie ja was: Sie wartet sich einen Wolf, bis dieses Flag endlich gesetzt ist.

Was soll denn passieren, wenn das Flag gesetzt wurde? Ich würde nämlich eine Semaphore (oder ein Event) verwenden, und einen Thead warten lassen (CPU-Belastung: 0.0%). Sobald das Flag gesetzt (oder die maximale Zeit gewartet) wurde, terminiert der Thread. Im OnTerminate des Threads wird das Ereignis aufgerufen (Flag gesetzt) oder eben nicht (Timeout abgelaufen).

In der Zwischenzeit steht die Anwendung zu 100% anderen Dingen zur Verfügung.

[moelski]

Moin !

Zitat:

Was soll denn passieren, wenn das Flag gesetzt wurde?

Ok, zum besseren Verständnis (und in der Hoffnung das vielleicht noch eine andere Idee bei rum kommt) ...

Es geht um eine Software die ein Ladegerät nach Daten abfragt. Dabei muss immer eine Sequenz aus 3 Befehlen gesendet werden. Aber Befehl 2 darf erst wenn Befehl 1 fertig ist. Und somit warte ich über ein Flag, ob der vorherige Befehl schon erfolgreich ausgeführt wurde. Wenn das Flag gesetzt ist, rennt das Prog weiter und sendet den neuen Befehl zum Lader.

Zitat:

Ich würde nämlich eine Semaphore (oder ein Event) verwenden, und einen Thead warten lassen (CPU-Belastung: 0.0%). Sobald das Flag gesetzt (oder die maximale Zeit gewartet) wurde, terminiert der Thread. Im OnTerminate des Threads wird das Ereignis aufgerufen (Flag gesetzt) oder eben nicht (Timeout abgelaufen).

Tja, das mit den Threads ist so eine Sache. Ich habe mich daran schon mal versucht, aber so recht war ich nicht erfolgreich. Du hättest für sowas nicht einen Codeschnipsel für mich?

Und jetzt muss ich erstmal nachlesen was eine Semaphore ist :gruebel:

[alzaimar]

Hi moelski,

Ah... RS-232? Dann ist es doch aber egal, ob die Anwendung bei 100% steht, oder? Du kannst die gesamte Kommunikation mit dem Ladegerät doch in einen Thread auslagern, dann soll der doch warten.

Einen Thread zu basteln ist relativ einfach:

Delphi-Quellcode:

Type
  TMyThread = Class (TThread)
  <Lokale Werte>
  Protected
     Procedure Execute; Override;
  Public
     Constructor Create (<Werte für den Thread>);
  End;

Constructor TMyThread.Create(<Werte für den Thread>);
Begin
  Inherited Create (True); 
  <Lokale Werte> := <Werte für den Thread>
  <Sonstige Vorbereitungen>
  Resume; // Jetzt geht lo-hos!
End;

Procedure TMyThread.Execute;
Begin
  Try
    <Hier steht der Code drin, den der Thread ausführen soll>
    <Dazwischen immer mal wieder ein :>
    If Terminated Then Exit;
  Finally
    <Etwaige Speicheranforderungen, Objekte etc. wieder freigeben>
  End
End;

Wenn Du auf die VCL oder irgendwelche Objekte, Variablen (außer die lokaen Werte) zugreifst, musst Du das kapseln. Sonst schreiben vielleicht 2 Threads gleichzeitig in eine Variable und das geht meist schief.

[moelski]

Moin !

Ok, angenommen ich kriege den Thread nu in den Griff.
Habe ich das Problem dann nicht verlagert ?

Denn dann wartet doch der Thread vor sich hin ?! Und das müsste doch dann auch CPU fressen, oder seh ich da nu was falsch?

Und was noch dazukommt ... Die Procedure die jetzt die Befehle sendet und wartet muss ja auch dann auf den fertigen Thread warten. :gruebel: :gruebel:

Ach ja und es ist RS232 :-)

[Luckie]

Zitat:

Zitat von Christian Seehase

Moin Michael,

Zitat:

Zitat von Luckie

Flag muss ausserdem global sein, wie willst du es sonst setzen, wenn er in der Schleife ist?

nein, denn das

Zitat:

Zitat von Luckie

Warum übergibst du denn um Gottes Willen einen Boolean Zeiger?

macht's möglich ;-)

OK, die Möglichkeit ist mir entgangen, aber trotzdem darf er nicht das CheckBox Objekt übergeben und warum auch überhaupt?

[alzaimar]

Erstmal ist es doch egal, wenn ein Thread wartet. Das einzig 'Häßliche' ist die CPÜ-Anzeige des Taskmanagers.

Du hast hier das Problem, das ein ereignisgesteuertes System (hier: Windows) auf streng sequentiell abzuarbeitende Jobs (RS232 Abfragen) stößt. Wenn man es gänzlich ohne Wartezeit macht (aber was spricht hier dagegen?), dann müsste man eine ereignisgesteuerte RS-232 Komponente nehmen, und einen DEA (Deterministischen Endlichen Automaten) basteln, aber das ist zu kompliziert für deinen Fall.

Ich weiss nicht, wie Du mit dem Ladegerät kommunizierst, aber ich habe so ein Tool, mit geht das sehr einfach, so etwa:

Delphi-Quellcode:

...
  MyRs232.OpenCom ('Com1',8600,NoParity,8,1);
  MyRs232.WriteString (#027+'AB'); // Ersten Befehl senden
  sAnswer := MyRs232.ReadString;   // Antwort auf den 1.Befehl
  If sAnswer<>'READY' Then
    Raise Exception.Create('Gerät nicht bereit';
  MyRs232.WriteString (#027+'XY');
  sAnswer := MyRs232.ReadString;
  If sAnswer<>'OK' Then
    Raise Exception.Create('Gerät hat nicht mit OK geantwortet';
...

So wie man es aus alten DOS-Tagen kennt.

Jedes WriteString und ReadString wartet eben, bis die Funktion ausgeführt wurde. Das kann man auch ereignisgesteuert machen, aber eher lagere ich das in einen Thread aus und rufe die Sequenz nur eben alle 1000ms auf. Wieso willst Du auch nonstop wissen, wie es dem Ladegerät geht?

Was Du machst, nennt man 'Polling', also aktives Abfragen eines Zustandes. Da ist es doch logisch, das die Anwendung CPU-eit verbrät.

[moelski]

Moin !

Zitat:

Wieso willst Du auch nonstop wissen, wie es dem Ladegerät geht?

Das ist der Sinn unserer Software :-D Siehe www.logview.info
Aber das nur am Rande ...

Zitat:

Ich weiss nicht, wie Du mit dem Ladegerät kommunizierst

Tja, da fangen die Probleme ja schon an. Unsere Anwendung hat bei dem Gerät zwei Formulare. Formular 1 übernimmt die grafische Auswertung der Daten. Hier werden die Daten auch empfangen. Und Forumlar 2 sendet Timergesteuert die Anforderungen. Also eine einfache Abfrage wie in DOS Zeiten ist da nicht machbar, weil die Teile Senden und Empfangen in vollkommen unterschiedlichen Programmteilen verarbeitet werden.

Zitat:

Was Du machst, nennt man 'Polling', also aktives Abfragen eines Zustandes.

Das ist mir auch bewusst das ich aktives Polling betreibe. Was ich mich halt nur frage ist, ob es nicht eine Möglichkeit gibt, auf das setzen eines Flags zu warten, ohne das Programm lahm zu legen.

Zitat:

Das einzig 'Häßliche' ist die CPÜ-Anzeige des Taskmanagers.

Hmm, aber ist es dann nicht auch so, das dieser Thread CPU verbrät? Ok, das Hauptprogramm läuft vermutlich unbeeindruckt von dem Warten auf den Zustand. Aber der Rest des Systems würde doch dann wieder ausgebremst, oder nicht? :gruebel:

[moelski]

Moin !

Noch ne Andere Idee ...

Diese procedure wartet x Millisekunden bevor die folgende Procedure weiter fortgesetzt wird.

Delphi-Quellcode:

procedure Snooze(Milliseconds: Integer);
var
  Tick: Int64;
  Event: THandle; 
begin 
  Event := CreateEvent(nil, False, False, nil); 
  try 
    Tick := GetTickCount + Int64(Milliseconds); 
    while (Milliseconds > 0) and 
          (MsgWaitForMultipleObjects(1, Event, False, Milliseconds, QS_ALLINPUT) <> WAIT_TIMEOUT) do 
    begin 
      Application.ProcessMessages; 
      Milliseconds := Tick - GetTickcount; 
    end; 
  finally 
    CloseHandle(Event); 
  end; 
end;

Wäre es nicht möglich diese procedure so umzubauen, dass sie eben nicht auf einen Timer reagiert, sondern auf ein Flag? Weil das Teil benutzt quasi 0% CPU ...

Ich habe im Moment nur überhaupt keine Vorstellung wo ich dann an der Funktion drehen müsste, damit das mit einem Flag funzt (wenn es überhaupt geht ?!). :gruebel:

Greetz Dominik

[Klaus01]

Delphi-Quellcode:

while (Flag^ = True) and (Now() < EndTime) do 
  begin 
    Snooze(100); 
    // Application.ProcessMessages;  wird ja schon im Snooze abgearbeitet
  end;

Grüße
Klaus