VCL Multithread zB. TBitMap Zugriff

[bernhard_LA]

ich bin auf der Suche nach Bugs in unserer Anwendung, als Ursache vermute ich das Thema "VCL, .... " und ThreadSafe programmieren

( siehe zb. http://www.delphipraxis.net/130497-v...absichern.html)

Es geht um folgendes Fehlerbild : GUI Anzeigen kommen nicht immer, Leinwand erlaubt kein Zeichnen -Fehlermeldung, ... anstelle einer gezeichneten Bitmap erhalte ich nur eine weiße Fläche ....

Gibt es Code beipiele , wie ich Ausgaben in die VCL als Threadsafe ... durchführe ... ich suche kleine Code beipiele um ein Konzept für das Bug Fixing unserer Anwendung zu erstellen.

[himitsu]

Eigentlich isses Einfach:

- alle Zugriffe auf nicht threadsichere VCL-Dinge über Synchronize erledigen

- Dinge, wo nur deine Codes drauf zugreifen (z.B. eine TList oder andere Variablen, Speicherblöcke, Dateien, Handles) über CriticalSection und Co. (wobei hier natürlich auch Synchronize ginge)




Synchronize sichert ab, da alle Zugriffe nur im Haptthread erfolgen und dadurch immer nur Einer gleichzeitig arbeiten kann.

CriticalSection sperrt Zugriffe für andere Threads, wärend ein Thread damit arbeitet.

ReadWriteSynchronizer erlauben gleichzeitige Lesezugriffe aber beim Ändern wird alles andere gesperrt.





Du kannst ein Bitmap gerne innerhalb eines Threads bearbeiten, aber die Übergabe, also Anzeigen, bzw. dea Kopieren des Inhalts davon, rüber zu VCL muß abgesichert werden.


Codebeispiele?
Für CriticalSections und Synchronize findet man jede Menge, wobei hier die auch schon OH genaug erklärt.

[bernhard_LA]

unter http://www.drbob42.com/uk-bug/hood-04.htm wird im Beispiel die nicht Thread sicheren VCL Object im Thread create übergeben, ist dies die beste Lösung zu diesem Thema ?

[himitsu]

Zitat von bernhard_LA:

ist dies die beste Lösung zu diesem Thema ?

Es kommt drauf an, was genau du machen willst.

Das Create wird noch im Hauptthread verarbeitet, daher kann man dort alles machen, was auch ohne Thread möglich ist.

Wenn die übergebenen Objekte nirgenwo in der VCL benutzt werden, also wenn die VCL, bzw. der Hauptthread oder ein anderer Thread nicht darauf zugreifen, dann kann man danach im Thread diese Objekte problemlos nutzen.

[Namenloser]

Also bei TBitmap bzw. TCanvas im speziellen reicht es nach meiner Erfahrung, (Bitmap.)Canvas.Lock/Unlock aufzurufen.

[himitsu]

Hmm, von der Absicherung her sollte das dann wohl der CriticalSection Sperrung entsprechen.

[bernhard_LA]

könnte ich mir durch diesen Ansatz eine ThreadSafe VCL Zusammenbasteln,
ich müsste halt die wichtigsten Funktionen innerhalb von .Create (....) oder .... bereitstellen; Mir gehts um das Konzept - möglichst flexibel - gut lesbar - einfach - Stabil .....

Delphi-Quellcode:

  THreadSafeMemo = class(TThread);


     Fmemo : Tmemo; 

      constructor Create(amemo : TMemo)

      procedure AddText (aString : String);

      .....
  end;


 ThreadSafeMemo.constructor Create(amemo : TMemo)
 begin
       Fmemo := Tmemo;
.....
end;

[Bernhard Geyer]

Zitat von himitsu:

Das Create wird noch im Hauptthread verarbeitet, daher kann man dort alles machen, was auch ohne Thread möglich ist.

Wenn die übergebenen Objekte nirgenwo in der VCL benutzt werden, also wenn die VCL, bzw. der Hauptthread oder ein anderer Thread nicht darauf zugreifen, dann kann man danach im Thread diese Objekte problemlos nutzen.

Nicht unbedingt. Das Hauptproblem von VCL-GUI-Controls ist ja das die Win32-Ressourcen Thead-Affine sind. D.h. ein (Fenster-)Handle darf nur im Thread verwendet werden indem er erzeugt wurde. D.h. will man ein (T)Bitmap im Thread verändern so muss es auch in diesem erzeugt werden.

[Namenloser]

Hmm, aber es ist doch möglich, selbst Fenster von fremden Anwendungen zu manipulieren (z.B. einen disableten Button zu enablen, SetWindowPos etc.)
Was Bitmaps angeht: Da habe ich gerade erst ein kleines Programm geschrieben, bei dem ein Thread auf ein Bitmap zeichnet, das im Constructor des Threads erzeugt wird (also somit noch im Hauptthread), und dieses regelmäßig auf das Canvas einer Form kopiert. Läuft absolut zuverlässig und stabil, solange für beide Canvasse jeweils Lock und Unlock aufgerufen wird.

Ich dachte das Problem bei der VCL wären eher globale Variablen, die intern zur Verwaltung dienen.

[Blup]

Zitat von NamenLozer:

Hmm, aber es ist doch möglich, selbst Fenster von fremden Anwendungen zu manipulieren (z.B. einen disableten Button zu enablen, SetWindowPos etc.)

Das macht man dann aber über Windowsnachrichten, die dann von dem für das Fenster zuständigen Thread abgearbeitet werden.

Zitat von NamenLozer:

Ich dachte das Problem bei der VCL wären eher globale Variablen, die intern zur Verwaltung dienen.

Wenn das so einfach währe, hätte Borland damals sicher auch eine threadsichere VCL gebaut.

Dein Beispiel mit dem Memo kann so nur stabil funktionieren, wenn der Thread alle Zugriffe und Aktionen mit dem Memo im Synchronize ausführt.