Synchronize mit Argumenten

[Viktorii]

Leider funktioniert es nicht.

Habe mal folgenden Versuch gemacht:

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    Memo1: TMemo;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    FMyThread: TMyThread;
    procedure progress(value: Integer);
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  Memo1.Clear;
  FMyThread := TMyThread.Create(true);
  FMyThread.Progress := progress;
  FMyThread.Resume;
end;

procedure TForm1.progress(value: Integer);
begin
  Memo1.Lines.Add('Value: ' + IntToStr(value));
  sleep(500);
end;

Delphi-Quellcode:

type
  TProgress = procedure(Value: integer) of object;

type
  TMyThread = class(TThread)
  private
    FValue: Integer;
    FProgress: TProgress;
    procedure SyncProgress;
  protected
    procedure Execute; override;
  public
    property Progress: TProgress write FProgress;

  end;

implementation

uses
  Windows, SysUtils;
{ TMyThread }

procedure TMyThread.Execute;
var
  i: Integer;
begin
  for i := 1 to 10 do
  begin
    FValue := i;
    Queue(SyncProgress);
    sleep(200);
    OutputDebugString(PWideChar('FValue: ' + IntToStr(FValue)));
  end;
end;

procedure TMyThread.SyncProgress;
begin
  FProgress(FValue);
end;

Die Ausgabe sieht so aus:

Zitat:

Value: 1
Value: 3
Value: 5
Value: 8
Value: 10
Value: 10
Value: 10
Value: 10
Value: 10
Value: 10

[DeddyH]

Und bei Synchronize stimmt das Ergebnis?

[Sir Rufo]

Na logisch stimmt das bei Synchronize.

In die Warteschlange kommt ja der Aufruf der Prozedur.
beim Abarbeiten wird die Prozedur ausgeführt.

Und bei der Verwendung von Queue (asynchron) hat sich der Wert von FValue eben schon wieder geändert.
Bei Synchronize schweigt ja alles, bis die Prozedur abgearbeitet wurde.

Für das Queue hilft also auch nur einen WerteQueue (mit CS absichern) die dann Stück für Stück abgearbeitet wird.

Nimm für die WerteQueue eine eigene CS, damit die auch nur dann blockiert ist, wenn dort Werte abgerufen oder eingetragen werden.

[Bummi]

@Sir Rufo
Der Zugriff über CS ist sicher sinnvoll, ändert aber nichts daran dass man sich im klaren sein muss wo der Unterschied zwischen Synchronize und Queue liegt und welchen Tod man sterben möchte.
Es wird Anwendungen geben bei es beispielsweise genügt wenn der Hauptthread einen gerade aktuellen Wert zu Anzeige bringt, hier wird Queue der richtige Ansatz sein. Wenn sichergestellt werden muss dass alle Messwerte auflaufen wird es auf Synchonize oder auf z.B. gemeinsam genutzte Array hinauslaufen, bei denen der Thread eine CS gesicherte "gültig bis" Property verwaltet, oder bei einfachen Datentypen direkt Messages.

[Sir Rufo]

@Bummi

Wenn man mit Queue arbeitet MUSS man den Zugriff auf die entsprechende Ressource (hier FValue) schützen. Andernfalls riskiert man einen Zugriffsfehler.

Bei Synchronize kann man sich das sparen, da zum Zeitpunkt der Übergabe Thread und Hauptthread im gleichen Threadkontext laufen. Bei Queue eben halt nicht.

Mit einer MessageQueue werden via Queue auch ALLE Nachrichten abgeliefert. Mit nur einer Resoource (hier FValue) natürlich nur der aktuelle Wert zum Zeitpunkt der Abfrage.

Hat man sich also entschlossen mit Queue zu arbeiten (weil man eben nur Daten in den Hauptthread schleusen will und von dem auch nichts direkt zurückhaben will und genau da macht es durchaus Sinn), dann ist eine kleine Liste mit den entsprechenden Nachrichten doch auch kein Problem mehr.

Nur sollte man dabei genau wissen, was man tut, sonst knallt es völlig unkontrolliert (und perverserweise auch nicht regelmäßig und je nach Häufigkeit des Zugriffs auch nicht wirklich oft ... aber es knallt halt

[Bummi]

@Sir Rufo

ich war schon vorher Deiner Meinung, meine Thread-Templates sind auch so aufgebaut.
Mir ging es nur darum festzustellen dass es wohl jedes mal abzuwägen gilt welche der Varianten (Queue/Synchronize) für den Anwendungsfall gerade sinnvoll ist.

Zitat:

Ich würde aber so gut wie immer statt Synchronize den Queue verwenden (manchmal muss halt Sync sein, aber beim reinen Abliefern von Informationen ...).

Es gibt IMHO auch Anwendungsfälle in denen z.B. kein Messwert verloren gehen darf (also durch einen späteren ersetzt werden).

BTW leicht offtopic, wie handhabst Du Syncs zwischen Threads und SubThreads (oder nebenläufigen Threads), also ohne Umweg über den Anwendungsthread?

[Sir Rufo]

Wieso gehen beim Queue Werte verloren? Klar, wenn man es falsch macht ja, aber wenn ich das Auto nicht richtig beherrsche fahre ich evtl. auch gegen den Baum.
Also am besten richtig machen

Bei meinen Queues gehen keine Werte verloren.
(und seit der anonymen Methoden geht halt auch das Queue ohne eigene Warteschlange)

Wichtig ist nur am Ende des Threads ein Synchronize zu machen, damit auch wirklich alle Queue-Einträge im Hauptthread verarbeitet wurden. Ansonsten kann es eben halt passieren, dass der Thread (FreeOnTerminate) sich einfach so auflöst und alle bis dahin nicht abgearbeitete Queue-Einträge aus selbigen Thread gehen sang und klanglos mit unter.

Zwischen den Threads (auch Hauptthread direkt zum Thread) geht das bei mir immer über eine CS.
Manchmal halt auch eine separate CS für den reinen Austausch dieser Daten, wenn es vom Ablauf geschickter ist und dadurch performanter wird.

ADD Daten von Thread zu Thread über den Hauptthread auszutauschen halte ich nicht für sinnvoll.
Der Hauptthread ist für den User und wird von dem quasi kontrolliert. Wenn der also Samba auf der Tastatur und Maus tanzt, dann könnte er damit auch die Threads beeinflussen.
Bei mir darf der das (wenn es nicht meine Maus/Tastatur ist)