Kann man also festhalten Queue ist besser als Synchronize?

Zitat:

Für das Setzen eines Hints oder eine Fortschrittsanzeige ist diese Synchronizität aber gar nicht notwendig

Heißt das, ich kann FormX.ProgressBarY.Position := in einem Thread ohne Synchronize aufrufen und komplett auf Queue ausweichen?

Verstehe ich das richtig?
Synchronize synchronisiert sofort und erst wenn das fertig ist geht es nach meinem Befehl, der in Synchronize() steht weiter
und Queue packt den Aufruf in eine ART Stack, es geht aber sofort weiter?

Nur kann Queue dann nicht Probleme machen wenn man folgendes Szenario hat?

markieren

Delphi-Quellcode:

var i: Integer;

i := 2;

TThread.Queue(nil, procedure begin i := 5; end);

if i = 5 then
 begin
 end;

Könnte es denn jetzt passieren, dass i := 5 ins Queue gesetzt wird aber erst so spät ausgeführt wird, dass if i := 5 nicht zutrifft, da i ja noch 2 ist?
Oder denke ich hier falsch?

Richtig, Queue() ist asynchron, Synchronize() ist synchron (höhö)

PS: Doch, genau in dem Fall willst du ganz sicher NICHT einen asynchronen Aufruf verwenden. Denn das Setzen auf fünf passiert praktisch garantiert NACH deiner Abfrage.

Könnte mein oben genanntes Problem denn eintreten?
i := 5 ist nur ein Beispiel.

Du hast zwei Möglichkeiten: Synchron (TThread.Synchronize(..) ) und asynchron (TThread.Queue(..) )

Wenn du die Auswirkungen/Resultate/Rückgaben des Codes den du im Kontext eines anderen Threads ausführen möchtest direkt brauchst, dann brauchst du TThread.Synchronize(..)
Das "Problem" wird garantiert auftreten, hier noch einmal das gleiche Beispiel, nur etwas ausführlicher:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TForm17.Button1Click(Sender: TObject);
begin
   TThread.CreateAnonymousThread(
      procedure()
      var
         capturedVariable: Integer;
      begin
         capturedVariable := 100;
         TThread.Queue(
            nil,
            procedure()
            begin
               capturedVariable := 42;
            end
         );

         case capturedVariable of
            100:
               Beep();
            42:
               begin
                  Beep();
                  Beep();
               end;
         else
            Beep(); Beep(); Beep();
         end;
      end
   ).Start();
end;

SendMessage und PostMessage synchronisieren sich selbstständig,
die Messages werden im Erstellungsthread der Komonenten verarbeitet, also innerhalb der MessageLoop. (bei der VCL im Hauptthread).

PostMessage ist asynchron (ist wie Queue)
SendMessage ist synchron (wie Synchronize)

Achtung: TThread.Queue im Haupthtread aufgerufen ist synchron, also wie Synchronize (k.A. wer da auf diese schwachsinnige Idee gekommen ist)
[edit] Seit wann gibt es ForceQueue?

Seit 10.1 Berlin

Zitat:

Das "Problem" wird garantiert auftreten, hier noch einmal das gleiche Beispiel, nur etwas ausführlicher:

Danke für das Beispiel. Dann werde ich Queue nur da anwenden, wo ich die Daten nicht sofort brauche (das heißt GUI-Änderungen und keine Variablen die ich unmittelbar nach dem Queue brauche).

Zitat:

SendMessage und PostMessage synchronisieren sich selbstständig,

Woran kann das den liegen, dass sich hier rein gar nichts tut? Laut diesem Beitrag soll es ja angeblich funktionieren https://www.entwickler-ecke.de/topic..._106970,0.html

CriticalSection
MultiReaderSingleWriter
Interlocked


Interlocked: Setzen von Integer, Booleans (LongBool) usw., also allem mit "4 Byte", bzw. in Registergröße.
InterlockedIncrement/InterlockedIncrement, InterlockedDecrement, InterlockedExchange, ..., bis hin zu Assembler (LOCK)

Zitat:

CriticalSection
MultiReaderSingleWriter
Interlocked

Ich verstehe nicht, was das jetzt mit SendMessage und der ProgressBar zu tun hat.

Zitat von Glados:

Woran kann das den liegen, dass sich hier rein gar nichts tut? Laut diesem Beitrag soll es ja angeblich funktionieren https://www.entwickler-ecke.de/topic..._106970,0.html

Ich habe das jetzt nicht alles gelesen, aber das hier scheint für mich bestens zu funktionieren:

zusammenfalten · markieren

Delphi-Quellcode:

unit Unit17;

interface uses
   System.SysUtils, System.Classes,
   Winapi.Windows,
   Vcl.Controls, Vcl.Forms, Vcl.StdCtrls, Vcl.ComCtrls;

type
   TMyThread = class(TThread)
      protected var
         progressbarHandle: THandle;
      protected
         procedure Execute(); override;
      public
         constructor Create(const progressbarHandle: THandle);
    end;

   TForm1 = class(TForm)
      ProgressBar1: TProgressBar;
      Button1: TButton;
      procedure Button1Click(Sender: TObject);
   end;

var
   Form1: TForm1;

implementation uses Winapi.CommCtrl;

{$R *.dfm}

{ TMyThread }

constructor TMyThread.Create(const progressbarHandle: THandle);
begin
   inherited Create(True);
   self.progressbarHandle := progressbarHandle;
end;

procedure TMyThread.Execute();
var
   percentDone: Integer;
begin
   percentDone := 0;

   while (not Terminated) do
      begin
         Inc(percentDone, 1);

         PostMessage(progressbarHandle, PBM_SETPOS, percentDone, 0);
         if (percentDone < 100) then
            TThread.Sleep(100)
         else
            Terminate();
      end;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
   myThread: TMyThread;
begin
   myThread := TMyThread.Create(ProgressBar1.Handle);
   myThread.FreeOnTerminate := True;
   myThread.Start();
end;

end.

Bonuspuntke für mehrmaliges Drücken des Buttons