TThread: Synchronize() priorisieren?

[Medium]

Statt der Events via Methodenzeiger bevorzuge ich mittlerweile eine doppelt gepufferte Datenhaltung und Windows Messages. Beispiel:

Delphi-Quellcode:

// Threadklasse
type
  TMyThread = class(TThread)
  private
    FThreadBuffer: TObjectList; // Hier schreibt der Thread seine Daten rein
    FGUIBuffer: TObjectList; // Hier liest nachher die GUI raus
    FBufferCS: TCriticalSection;
    FForm: HWND;
    function GetItems: TObjectList;
    function GetItemCount: Integer;
  protected
    procedure Execute; override;
  public
    constructor Create(aForm: HWND);
    procedure LockData;
    procedure ReleaseData;
    property Items: TObjectList read GetItems;
    property ItemCount: Integer read GetItemCount;
  end;

const
  WM_MY_DATA_UPDATE = WM_USER + 1234;

implementation
  
constructor TMyThread.Create(aForm: HWND);
begin
  inherited(false);
  FForm := aForm;
  // Initialisierung der Buffer etc.
end;

procedure TMyThread.LockData;
begin
  FBufferCS.Enter;
end;

procedure TMyThread.ReleaseData;
begin
  FBufferCS.Leave;
end;

procedure TMyThread.GetItems: TObjectList;
begin
  FBufferCS.Enter;
  try
    result := FGUIBuffer;
  finally
    FBufferCS.Leave;
  end;
end;

procedure TMyThread.Execute;
begin
  repeat
    DoSlowStuffWith(FThreadBuffer);

    FBufferCS.Enter;
    try
      FGUIBuffer.Clear; // OwnsObjects!
      CloneAllItemsFromThreadBufferTo(FGUIBuffer);
    finally
      FBufferCS.Leave;
      PostMessage(FForm, WM_MY_DATA_UPDATE, 0, 0);
    end;
  until Terminated;
end;

Delphi-Quellcode:

// Formularklasse
type
  TMainForm = class(TForm)
  private
    procedure OnMyDataUpdate(var msg: TMessage); message WM_MY_DATA_UPDATE;
  public
  end;

implementation

procedure TMainForm.OnMyDataUpdate(var msg: TMessage);
begin
  myThreadInstance.LockData;
  try
    WriteItemsToGrid(myThreadInstance.Items);
  finally
    myThreadInstance.ReleaseData;
  end;
end;

Dabei ist es dann recht egal wie lange es dauert die Daten im Thread zusammenzustellen, die GUI muss maximal auf das Kopieren der ListItems warten, was in wenigen Millisekunden erledigt ist. Dadurch wird die GUI wunderbar flott, egal wie riesig z.B. die Tabelle ist aus der die Daten erst abgerufen werden müssen im Thread. Zudem muss der Thread nicht erst warten bis die GUI all ihren Krams ins Grid gepackt hat, der kann ja ruhig schon mal den nächsten Zyklus abrufen.

UND: Es ist dem Thread an sich völlig egal wer seine Daten abholt, wie der Abholer sie dann interpretiert, und ob überhaupt ein Abholer vorhanden ist.

Der Code ist natürlich nur eine ganz grobe pseudocodeähnliche Skizze, und je nach Anwendungsfall kommen natürlich auch mehrere verschiedene Buffer in Frage. Auch der Typ der Buffer ist an sich egal, wichtig ist nur, dass wirklich KOPIEN existieren, nicht nur Referenzen auf dieselben Instanzen in die der Thread rein schreibt. Auch ist ein Queue-ähnlicher Aufbau denkbar, bei dem erst Items in die Thread-Liste gefüllt werden, die dann auf einen Schlag in die GUI-Liste übertragen, und dann von der GUI abgeholt und gelöscht werden. Zentral ist aber die doppelte Datenhaltung um GUI und Thread nicht zu stark aufeinander warten zu lassen, und das Signaling via Windows Message. (Gerne packe ich auch noch die self-Referenz des sendenden Threads in wParam oder lParam, damit das Formular auch gleich den richtigen Absender an der Hand hat wenn es mehrere parallele gleichtypige Threads gibt.)

[Delphi-Laie]

Zitat von romber:

Besteht die Möglichkeit, einen Thread so zu priorisieren, dass er immer Vorrang bei synchronisiertem Zugriff auf die GUI hat?

Das wurde hier ja schon verneint, ggf. bringt es Dich aber ein Stück weiter, diesen einen Thread wenigstens eine höhere Priorität zuzuweisen, als die anderen haben (ggf. auch zugewiesen bekamen, evtl. sogar absichtlich ein deutlich erniedrigte).

Generell ist Windows für Echtzeitanforderungen ungeeignet.

[romber]

Zitat von Uwe Raabe:

...Es kann allerdings passieren, daß bei Queue die Methode gar nicht abgearbeitet wird, da bei Freigabe der TThread-Instanz alle noch vorhandenen Queue-Events gelöscht werden. Dem kann man aber vorbeugen, in dem man anstatt der einfachen Queue-Methode die gleichnamige Klassenmethode mit dem zusätzlichen TThread-Parameter an erster Stelle verwendet und diesen als nil übergibt. Dann kann das zwar theoretisch immer noch passieren, aber nur wenn das ganze Programm vor Abarbeiten des Queue-Events beendet wird. Das wäre übrigens bei Synchronize auch der Fall.

Aber auch hier darf die mit Queue aufgerufene Methode nicht innerhalb des Threads deklariert werden, oder?

[Mavarik]

Zitat von romber:

Zitat von Uwe Raabe:

...Es kann allerdings passieren, daß bei Queue die Methode gar nicht abgearbeitet wird, da bei Freigabe der TThread-Instanz alle noch vorhandenen Queue-Events gelöscht werden. Dem kann man aber vorbeugen, in dem man anstatt der einfachen Queue-Methode die gleichnamige Klassenmethode mit dem zusätzlichen TThread-Parameter an erster Stelle verwendet und diesen als nil übergibt. Dann kann das zwar theoretisch immer noch passieren, aber nur wenn das ganze Programm vor Abarbeiten des Queue-Events beendet wird. Das wäre übrigens bei Synchronize auch der Fall.

Aber auch hier darf die mit Queue aufgerufene Methode nicht innerhalb des Threads deklariert werden, oder?

Doch!

[romber]

Zitat von Mavarik:

Doch!

Bei mir werden die Threads automatisch freigegeben. Sollte der Thread zum Zeitpunkt des Aufrufs der Queue-Methode nicht mehr vorhanden sein, was wird denn aufgerufen?

[Uwe Raabe]

Zitat von romber:

Bei mir werden die Threads automatisch freigegeben. Sollte der Thread zum Zeitpunkt des Aufrufs der Queue-Methode nicht mehr vorhanden sein, wie soll die Thread-Methode von Haupthread aufgerufen werden?

Deswegen sollst du ja auch nil als Parameter übergeben. Dann überlebt das Queue auch das Ende des Threads. Die übergebene Methode ist ja eine Anonyme Methode. Obwohl sie in deiner Thread-Methode deklariert wird, gehört sie damit nicht wirklich zu der Thread-Instanz.

[romber]

Zitat von Uwe Raabe:

Deswegen sollst du ja auch nil als Parameter übergeben. Dann überlebt das Queue auch das Ende des Threads. Die übergebene Methode ist ja eine Anonyme Methode. Obwohl sie in deiner Thread-Methode deklariert wird, gehört sie damit nicht wirklich zu der Thread-Instanz.

Ok, also doch als anonyme Methode. Etwa so?

Delphi-Quellcode:

TThread.Queue(nil, procedure()
                   begin
                     MachWas;
                   end);

Was ich gemeint habe, ist dass die Methode nicht als Teil des Threads deklariert werden darf:

Delphi-Quellcode:

type
  TMeinThread = class(TThread)
  //...
  protected
    procedure Execute; override;
    procedure DoDataChanged; 
end;

procedure TMeinThread.Execute;
begin
  //..
  TThread.Queue(nil, DoDataChanged);
end;  

procedure TMeinThread.DoDataChanged;
begin
  myCustomDataSource.DataChanged;
end;

[Uwe Raabe]

Zitat von romber:

Ok, also doch als anonyme Methode. Etwa so?

Delphi-Quellcode:

TThread.Queue(nil, procedure()
                   begin
                     MachWas;
                   end);

Genau so! Allerdings darf MachWas dann auch nicht voraussetzen, daß die Thread-Instanz noch existiert, wenn du das nicht sicher stellen kannst.

[romber]

Perfekt, vielen Dank!