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

[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 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?

[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 ?!).

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