Hallo DP-Community,

ich bin eben am Überlegen, wie ich am effektivsten meine Komponenten aktualisiere.

Folgende Umgebung:

Ich verwende XE5 Rad Studio (Delphi), Firemonkey, meine Gui Komponenten sind Eigenentwicklungen und kommen ohne Styles aus. Das Programm läuft ausschließlich unter Windows (Win7 -> 8.1)

Situation:

Jede dieser Komponenten ist mit einer nichtvisuellen Komponent verbunden, die via I/O Thread beispielsweise TCP Datenpakete sendet und entgegen nimmt und die ausgewerteten Daten in einer persistenten Propertyklasse verspeichert.
Das Lesen/Schreiben dieser Werte ist via CriticalSections threadsafe. Ein gesondertes Property für einen Updatehinweis steht auch zur Verfügung.

Teile dieser Daten sollen nun visuell dargestellt werden, sofern sich eine Änderung ergab. Der I/O Thread soll nun nicht durch ein Synchronize verlangsamt werden.

So würde ich nun der visuellen Komponente einen weiteren Thread erzeugen, der ca. alle 25 ms überprüft, ob die nichtvisuelle Komponente eine Änderung erfahren hat. Gab es eine Änderung, so legt sie eine lokale Kopie der Propertyklassse an
und wird im Falle einer Änderung die Updateprozedur via Synchronize aufrufen, ansonsten legt sich der Thread via Sleep(n) schlafen...

Frage:

Ist dieser Lösungsansatz so brauchbar oder gäbe es bessere Ansätze, beispielsweise via TMessages oder klassen wie OmniThread? (siehe http://www.omnithreadlibrary.com/)

Vielen Dank für Eure Antworten vorab!

Grüße,

Peter

TThread.Queue ist eine Alternative: es blockiert den Worker-Thread nicht, sondern stellt den im Hauptthread auszuführenden Code in eine Warteschlange.

Zitat:

"Im Gegensatz zu Synchronize ist die Ausführung des aktuellen Threads zum Fortsetzen zulässig. Der Haupt-Thread verarbeitet alle Methoden aus der Warteschlange."

Zitat von mjustin:

TThread.Queue ist eine Alternative: es blockiert den Worker-Thread nicht, sondern stellt den im Hauptthread auszuführenden Code in eine Warteschlange.

Zitat:

"Im Gegensatz zu Synchronize ist die Ausführung des aktuellen Threads zum Fortsetzen zulässig. Der Haupt-Thread verarbeitet alle Methoden aus der Warteschlange."

Hmmm, ich sollte doch öfters mal wieder die Doku durchlesen - danke vielmals!

Um das Problem eines asynchronen Mehrfachaufrufes zu entgehen, böte sich eine abgeleitete TObjectListe an. Vor dem Queue(Queueprozedur) Aufruf wird ein neuer Eintrag angelegt, CS berücksichtigen.

In der Queueprozedur die Liste via CS locken, den Count dieser Liste überprüfen, ist dieser > 0, dann den letzten Werteeintrag ausgeben, danach alle Elemente löschen, CS unlocken.
Der gegebenenfalls nachfolgend vorhandene, eingequeute Aufruf kann sich, sofern keinen neuen Einträge in der TObjectListe vorhanden sein, dann freinehmen...

Edit: Anstatt der TObjectList wäre wohl eine TObjectQueue interessanter...

Keine Panik, um den "asynchronen Mehrfachaufruf" brauchst du dir eigentlich keinen Kopf machen, solange du das nicht vollmüllst

zusammenfalten · markieren

Delphi-Quellcode:

unit EmbeddedThread;

interface

uses
  System.Classes;

type
  TSubject = class
  private type
    TSubjectData = record
      Value : Integer;
    end;

    TWorkThread = class( TThread )
    private
      FSubject : TSubject;
      FData : TSubjectData;
    protected
      procedure Execute; override;
      procedure QueueData;
    public
      constructor Create( ASubject : TSubject );
    end;
  private
    FWorkThread : TWorkThread;
    FData : TSubjectData;
    FOnChange : TNotifyEvent;
    procedure SetData( const Value : TSubjectData );
    procedure DoNotifyChange;
    function GetValue : Integer;
  public
    constructor Create;
    destructor Destroy; override;

    property Value : Integer read GetValue;
    property OnChange : TNotifyEvent read FOnChange write FOnChange;
  end;

implementation

{ TSubject.TWorkThread }

constructor TSubject.TWorkThread.Create( ASubject : TSubject );
begin
  inherited Create( False );
  FSubject := ASubject;
end;

procedure TSubject.TWorkThread.Execute;
var
  LStep : Integer;
begin
  inherited;
  while not Terminated do
  begin
    Sleep( 250 );

    if FData.Value = 100 then
      LStep := - 1
    else if FData.Value = 0 then
      LStep := 1;

    FData.Value := FData.Value + LStep;
    QueueData;
  end;
end;

procedure TSubject.TWorkThread.QueueData;
begin
  Queue(
      procedure
    begin
      FSubject.SetData( FData );
    end );
end;

{ TSubject }

constructor TSubject.Create;
begin
  inherited;
  FWorkThread := TWorkThread.Create( Self );
end;

destructor TSubject.Destroy;
begin
  FWorkThread.Free;
  inherited;
end;

procedure TSubject.DoNotifyChange;
begin
  if Assigned( OnChange ) then
    OnChange( Self );
end;

function TSubject.GetValue : Integer;
begin
  Result := FData.Value;
end;

procedure TSubject.SetData( const Value : TSubjectData );
begin
  FData := Value;
  DoNotifyChange;
end;

end.

Ich weiß nicht ob ich es falsch verstanden habe oder sonstwas, aber gibt es für sowas nicht auch noch die CriticalSections? Oder können die in diesem Fall nicht benutzt werden?

Zitat von Aviator:

Ich weiß nicht ob ich es falsch verstanden habe oder sonstwas, aber gibt es für sowas nicht auch noch die CriticalSections? Oder können die in diesem Fall nicht benutzt werden?

Theoretisch ja, aber beim Zugriff über eine CS kann der WorkerThread ausgebremst werden.

Danke für die Info. Jetzt weiß ich aber auch was mit CS gemeint war

Zitat von Sir Rufo:

Keine Panik, um den "asynchronen Mehrfachaufruf" brauchst du dir eigentlich keinen Kopf machen, solange du das nicht vollmüllst

markieren

Delphi-Quellcode:

unit EmbeddedThread;

... snip ...
end.

Um es mit Terry Pratchett zu sagen: Potzblitz! Ja die Anregung mit Queue und Workerthread ist toll und sollte auch viel durch das Weglassen der CS erheblich performanter sein
Danke vielmals und Grüße,

Peter

Problem ist nur, das Du dann u.U. den Hauptthread zumüllst, wenn Du deine Controls zu oft ansprichst (also 'Queue' zu oft aufrufst). Das Resultat ist dann ein flüssig laufender Hintergrundthread mit einer stockenden und u.U. für Minuten blockierten UI.

Zitat von Buddelfish:

Problem ist nur, das Du dann u.U. den Hauptthread zumüllst, wenn Du deine Controls zu oft ansprichst (also 'Queue' zu oft aufrufst). Das Resultat ist dann ein flüssig laufender Hintergrundthread mit einer stockenden und u.U. für Minuten blockierten UI.

Das ist klar - das kürzeste visuelle Update im Störfall findet nach 25 ms statt (schneller "sehen" wir ja nichts...), in der Regel checke ich die Maschinenstati wie Produktgeschwindigkeit ein mal pro Sekunde pro Gerät. Aber mal sehen, wie es sich ergibt.

Und da ich alle Elemente wie Checkboxen, Radiobuttons, div Buttons, Edits, etc von TControl abgeleitet nachgebaut habe, geht das Zeichnen recht flott und FMX macht meist das, was ich will