Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi Weitere Synchronisierungsmöglichkeiten ? (https://www.delphipraxis.net/160454-weitere-synchronisierungsmoeglichkeiten.html)

geskill 12. Aug 2011 14:47

AW: Weitere Synchronisierungsmöglichkeiten ?
 
Zitat:

Zitat von Sir Rufo (Beitrag 1100721)
Allerdings ist eine CriticalSection auch ein sehr harter Eingriff der alle beteiligten Threads ausbremsen kann bis zum Deadlock.

Entstehen diese Deadlocks durch Fehler vom Programmierer oder durch die Komponente selber?

Weil ich habe das Demo Programm gerade etwas geändert, sodass 2 Threads in ein Memo schreiben (dauerhaft). Nebenbei klicke ich auf einen Button der mehrere Male etwas in das Memo schreibt. Wenn man das Programm nun etwas länger laufen lässt und ausgiebig auf den Button klickt wird es früher oder später zu einem Deadlock kommen.

Im Debugger unter Thread Status steht dann z.b. sowas:
Code:
Projekt1.exe
 - 5516 | Ausführbar
 -  996 | Ausführbar
 - 4700 | Ausführbar |   |   | Blockiert beim Aufruf von SendMessage an ein Fenster im Besitz von Thread 5516
Mir ist schon klar, wenn ich einen Thread schlafen lege, welcher gerade innerhalb des Locks ist, dass es so zu einem Deadlock kommt.
Könnte es sein, dass es unter extremen Bedingungen (wildes Kicken auf einen Button) dazu kommt, dass es der Komponente zuviel wird und sie dann selber Aussetzer macht?

Beim googeln bin ich auch gerade auf folgenden Artikel gestoßen:
http://dn.embarcadero.com/article/28258
Dort steht im Code ein Kommentar von wegen:
Zitat:

//Still important to synchronize VCL calls
Deshalb war ich auch verwirrt und dachte, wie im Beispiel ist ein Synchronize-Befehl wichtig.

EDIT:
Der Button auf dem Formular benutzt ja auch den Lock, obwohl es an dieser Stelle unnötig ist, da man ja schon im Hauptthread befindet. Ja das sollte das Problem sein :(

geskill 14. Aug 2011 16:32

AW: Weitere Synchronisierungsmöglichkeiten ?
 
Aus meiner Sicht wäre die einfachste Lösung einfach vor dem Betreten der CS anzufragen, ob man sich im Hauptthread befindet und nur wenn nicht den Lock zu setzten und später wieder zu öffnen. Nur irgendwie kommt mir dies ein bisschen komisch vor, denn warum hat man dies dann nicht gleich in die CS-Komponente integriert?
Um das nachträglich einzubauen kann man ja auch ganz einfach mit einer abgeleiteten Klasse arbeiten, so hält sich der Aufwand in Grenzen.

Delphi-Quellcode:
procedure TIMemo.SetValue(A: string);
begin
  if not(GetCurrentThreadId = MainThreadID) then
    FMultiReadExclusiveWriteSynchronizer.BeginWrite;
  try
    FMemo.Lines.Text := A;
  finally
    if not(GetCurrentThreadId = MainThreadID) then
      FMultiReadExclusiveWriteSynchronizer.EndWrite;
  end;
end;

himitsu 14. Aug 2011 16:49

AW: Weitere Synchronisierungsmöglichkeiten ?
 
Laß solche Spiele, wie diese Locks.
Ja, damit kann absichern, daß merhere Threads gleichzeitig auf diese Eigenschaften zugreifen, aber die VCL nutzt und kennt diesen Lock nicht, weswegen sie hier auch ohne den Lock zu beachten gleichzeitig auf diese Eigenschaften/Werte zugreifen würde, selbst wenn du dort eine Spere drin hast.

Synchronisiere dich, wie es der Andere auch macht, mit dem VCL-Thread, wenn du auf eine VCL-Komponente zugreifen willst.
Delphi-Referenz durchsuchenTThread.Synchronize


Alle Zeitangaben in WEZ +1. Es ist jetzt 16:24 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz