TThread: Daten von Mainthread holen --> Synchronize notwendig?

[Helmi]

Zitat:

Zitat von jaenicke (Beitrag 1544444)

Dann führst du das ReceiveString aber auch innerhalb des Locks aus, obwohl es dafür gar keinen Grund gibt. Besser ist es, wenn du alles fertig machst und dann nur noch in dem abgesicherten Teil die Zielvariable schreibst.

Denn je länger du Threads blockierst, desto eher übersiehst du mögliche Deadlocks, sprich dass sich zwei Threads gegenseitig blockieren, weil beide auf den anderen warten (z.B. einer im TMonitor.Enter, der andere in einem Synchronize, jetzt nur als Beispiel). Die Gefahr besteht hier nicht, aber trotzdem sollte man in einem Lock, sprich hier zwischen Enter und Exit, so wenig Code wie möglich ausführen.

ah ok - Danke für die Info.

Also dann eher so:

Delphi-Quellcode:

procedure TMainForm.Thread_UDP_ReceiveString(var Text: String);
var
  S: String;

begin
  S := '';

  If idUDPClient.Connected then
    S := IdUDPClient.ReceiveString(-1, TEncoding.UTF8);

  System.TMonitor.Enter(ClientThread);
  try
    Text := S;

  finally
    System.TMonitor.Exit(ClientThread);
  end;
end;

[jaenicke]

Ja, genau. Wie schon geschrieben:
Hier ist es nicht relevant, aber gewöhne es dir besser gleich so an.

Und manchmal stellt sich dann ja auch heraus, dass eine weitere Verarbeitung gar nicht nötig ist, man den Teil mit TMonitor also gar nicht ausführen muss. Das kann man dann vorher noch prüfen.

[himitsu]

Jupp, prinzipiell kannst du dir dieses TMonitor wie eine CriticalSection vorstellen.
Außer dass du dir dort erst eine CriticalSection-Erstellen mußt und dann CS.Enter und CS.Leave nutzt.
Bei TMonitor ist dieser Speicherplatz/Instanz bereits in jedem einzelnen TObject integriert.

TThread.Synchronize und TThread.Queue lassen den jeweioligen Code im Hauptthread laufen.
Codes im Hauptthread sind bereits im Hauptthread und müssen natürlich nicht nochmal abgesichet werden.
Somit läuft jeder Zugriff nur noch im Hauptthread, also IMMER nur jeweils einer gleichzeitig und somit gibt es keine Konflikte.

SendMessage und PostMessage ... dort werden die Messages im Thread der Komponente ausgeführt (wo diese Komponente erstellt wurde) .... bei der VCL normal der Hauptthread.
Also auch hier wieder alles innerhalb des selben Threads und somit sicher.

Interlocked, bzw. Atomic, sowie LOCK im Assembler, blocken nur für diesen einen CPU-Befehl den Zugriff durch andere CPU-Kerne.
PS: Die Referenzzählung von Interfaces, Strings (LongStrings) und dynamischen Arrays nutzt das.



Und dann gibt noch brutalere Sachen ala TMREWSync/TMultiReadExclusiveWriteSynchronizer, für Dinge wo man oft liest (wenn es in sich thread-save ist) und seltener "unsicher" schreibt.
Mehrere können also gleichzeitig lesen, aber sobald EINER schreiben will, warten alle Anderen so lange.


Es gibt z.B. auch ThreadedList (normal oder als generic), wo man mit Add einfach "blind" reinschreiben kann (intern eine CriticalSection)
und beim Auslesen mal kurz "selbst" die Liste sperrt, im gesichert auf den Inhalt zuzugreifen.

Einige Implementationen bieten auch einfache Push- und Pop-Methoden, welche, wie Add, in sich abgesichert sind.
Einer/mehrere Threads schieben was rein ... einer/mehrere andere Threads holen sich war raus (falls es was gibt) ... und alles automatisch abgesichert.