Wenn Du den Setter von FOnNext mit einer CS verriegelt hast spricht IMHO nichts dagagen, sonst könnte bei (wirst Du nicht machen) gleichzeitigen Zugriff Müll in FOnNext stehen.

Wenn es nicht notwendig ist, dass diese "Message" synchron zum (bzw. im) Thread läuft, kannst du auch tatsächliche Windows Messages an dein Fensterhandle schicken, und dort mit einem Eventhandler reagieren. (SendMessage()) Das würde das ganze noch eine Spur mehr entkoppeln, ist aber daran gebunden, dass im Handler weder Thread auf MainForm noch MainForm auf Thread Felder zugreifen. So angelegte Konzepte "behagen" mir in der Regel mehr, als harte synchrone Callbacks, zumal man mit zu vielen letzterer den Nutzen von Threads auch gerne mal schmälern bis vernichten kann.

Im Prinzip ist diese Lösung zulässig:

markieren

Delphi-Quellcode:

    CS.Enter;
    try
      If Assigned(FOnNext) Then
        Syncronize(MessageNext);
    finally
      CS.Leave;
    end;

Aber man muss dann auch den Zugriff aus dem Hauptthread auf das Property "OnNext" mit CS schützen.
Damit würde aber in der Ereignisbehandlung "OnNext" im Hauptthread bei einem eventuellen Zugriff auf das Property "OnNext" des SaveThread ein Deadlock entstehen.

In der ursprünglichen Variante ist ein Schutz nicht notwendig, da auf FOnNext grundsätzlich nur im Hauptthread zugegriffen wird.
Ich denke es spricht hier aber nichts dagegen, auf "Assigned(FOnNext)" zusätzlich auch im Thread ohne CS zu prüfen, um unnötige Aufrufe von "Syncronize" zu vermeiden.