Variable eines Record geht beim Multithreading verloren

[Uwe Raabe]

Der Parameter M ist innerhalb der anonymen Methode nur bis zu ihrem Ende gültig. Der Code im Queue-Aufruf findet aber später statt (bei Synchronize ist das nicht der Fall).

Wie du schon bemerkt hast, kannst du das über eine lokale Variable lösen, die dann auch innerhalb der anonymen Queue-Methode gültig ist. Das kann anstatt der einzelnen Variablen p und i auch eine Variable vom Typ MyRecord sein.

Delphi-Quellcode:

procedure TForm1.btnEventClick(Sender: TObject);
begin
  TMessageManagerClass.DefaultManager.SubscribeToMessage(MyMessage,
  procedure(const Sender: TObject; const M: System.Messaging.TMessage)
  var
    bstr : string;
    my: MyRecord;
  begin
    bstr := (TThread.CurrentThread.ThreadID = MainThreadID).ToString();

    my := MyMessage(M).Value;

    TThread.Queue(nil, procedure
    begin
      edtEvent.Text := my.Str + my.I.ToString + '/' + bstr + '/' + (TThread.CurrentThread.ThreadID = MainThreadID).ToString();
    end);

  end);

  EventThread.Create();
end;

[j.zT]

Zitat von Uwe Raabe:

Der Parameter M ist innerhalb der anonymen Methode nur bis zu ihrem Ende gültig. Der Code im Queue-Aufruf findet aber später statt (bei Synchronize ist das nicht der Fall).

Wie du schon bemerkt hast, kannst du das über eine lokale Variable lösen, die dann auch innerhalb der anonymen Queue-Methode gültig ist. Das kann anstatt der einzelnen Variablen p und i auch eine Variable vom Typ MyRecord sein.

Delphi-Quellcode:

procedure TForm1.btnEventClick(Sender: TObject);
begin
  TMessageManagerClass.DefaultManager.SubscribeToMessage(MyMessage,
  procedure(const Sender: TObject; const M: System.Messaging.TMessage)
  var
    bstr : string;
    my: MyRecord;
  begin
    bstr := (TThread.CurrentThread.ThreadID = MainThreadID).ToString();

    my := MyMessage(M).Value;

    TThread.Queue(nil, procedure
    begin
      edtEvent.Text := my.Str + my.I.ToString + '/' + bstr + '/' + (TThread.CurrentThread.ThreadID = MainThreadID).ToString();
    end);

  end);

  EventThread.Create();
end;

Danke für die Antwort. Es macht Sinn, dass die Variable out of scope geht und gecleared wird. Dann macht für mich allerdings keinen Sinn, warum der Integer i weiterhin geschrieben werden kann.

Setzt Delphi strings auf '' wenn sie out of scope gehen und bei Integern wird nur der Speicher nur für Wiederverwendung freigegeben, aber nicht auf 0 gesetzt?
Wenn das Zutrifft, ist es dann einfach nur Zufall, dass der Speicher des Integer einfach nicht wiederverwendet wurde und deshalb die Zahl die gleiche ist?

[TomyN]

Genau. Gerade auch im Debugger 'halten' Variablen(-inhalte) manchmal länger als sie müssten.
Später dann auf einem Kundenrechner tun sie das dann plötzlich nicht mehr.

[himitsu]

Bzw. jetzt hat Emba gesagt, dass Variblen garnicht mehr so lange halten müssen, wie man denkt und wie bisher es "immer" war.

Ich würde ja den Thread zu suchen, aber ....

[Uwe Raabe]

Zitat von j.zT:

Dann macht für mich allerdings keinen Sinn, warum der Integer i weiterhin geschrieben werden kann.

Setzt Delphi strings auf '' wenn sie out of scope gehen und bei Integern wird nur der Speicher nur für Wiederverwendung freigegeben, aber nicht auf 0 gesetzt?
Wenn das Zutrifft, ist es dann einfach nur Zufall, dass der Speicher des Integer einfach nicht wiederverwendet wurde und deshalb die Zahl die gleiche ist?

Nein. Was hier zum Tragen kommt nennt sich Variablenbindung anonymer Methoden (Stichwort Closure). Die Verwendung der Variablen innerhalb der anonymen Methode sorgt intern dafür, dass die Variable nicht wie üblich im lokalen Bereich der umgebenden Methode gespeichert wird, sondern in einem separaten Bereich, der im Scope der anonymen Methode(n) liegt.

In deinem Beispiel werden p und i im Closure erfasst weil sie als Variablen deklariert sind. Der Parameter wird zwar auch erfasst, ist aber eine Instanz einer TMessage-Klasse, die nach dem SendMessage wieder freigegeben wird. Daher enthält sie beim späteren Ausführen der Queue-Methode einen undefinierten Inhalt.