TBitmap ist NICHT threadsave

[Bernhard Geyer]

Zitat von Delphi-Laie:

Zitat von Sir Rufo:

Die Aussage von Marco Cantu dazu lautet "TBitmap ist niemals für die Verwendung ausserhalb des MainThreads gedacht gewesen." (egal ob VCL/FMX).

In meinem Sortierkino läuft TBitmap in Extra-, also Nicht-VCL- bzw. Nichtmainthreads wie gewünscht.

Das Problem ist die wechsel des Threads und hier das Hauptproblem auf MS/Windows-Seite.
Alle GUI-Ressourcen von Windows sind nur im erzeugenden Thread gültig.
D.h. wenn du dein Bitmap nur in einem Thread erzeugst, bearbeitest und freigibst ist alles gut.
Damit hat auch die VCL kein Problem da hier keine weiteren Abhängigkeiten zu Formular, Screen und Co. existiert.

[bernau]

Zitat von Bernhard Geyer:

Alle GUI-Ressourcen von Windows sind nur im erzeugenden Thread gültig.
D.h. wenn du dein Bitmap nur in einem Thread erzeugst, bearbeitest und freigibst ist alles gut.

Und das ist es anscheinend nicht.

[himitsu]

Kämpf dich doch mal durch den Code von TBitmap,
also vorallem wo das Canvas her kommt und speziell die darin vorhandenen TPen oder TBrush.

Da landet man z.B. beim TResourceManager, der die Resourcen threadabhängig verwaltet.

[Kraisel]

Hallo Zusammen,

OK, ... scheint also doch immer noch ein kleines Problem mit sehr unterschiedlichen Erfahrungen zu sein.

Wie ich schon sagte, ist mir seit den Anfängen von Delphi klar, dass vieles in der VCL bzw. in FMX NICHT threadsave ist. Und es ist auch richtig, dass man grundsätzlich unterstellen sollte, dass alles, was man benutzt, vielleicht NICHT threadsave ist.

Ich hatte aber gehofft, dass ich in einem Thread eine FMX-Bitmap mit Map öffnen kann und dann selber Pixel lesen und/oder manipulieren kann. Aber selbst das geht eben in 1..10 % der Fälle schief und man merkt es nicht, da evtl. nur einige Pixel falsch sind. Das hatte ich einfach nicht erwartet.

Wohlgemerkt, ein Synchronize über den Bmp-Methoden im Thread und alles ist wieder gut. Deshalb gehe ich auch davon aus, dass mein Test OK ist, was man natürlich auch noch hinterfragen kann.

Wie Harry vorgeschlagen hat, werde ich deshalb, wenn ich Zeit habe, meinen Test aus meinem Framework separieren und hier hochladen. Das kann aber etwas dauern, da ich wie 'immer' unter Zeitmangel leide.

[Sir Rufo]

Es gibt einen Unterschied zwischen threadsafe und threadaffin. Die meisten Klassen sind nicht threadsafe aber - gottlob - auch nicht threadaffin.

• threadsafe
  Von jedem Thread kann auf die Eigenschaften der Klasse zugegriffen werden.
• threadaffin
  Auf die Eigenschaften der Klasse darf nur im Erzeuger-Thread zugegriffen werden
• ganz blöd
  Die Klasse ist noch mit einem globalen (oder wie auch immer aufgehängtem) Kontext verwoben, der auch noch threadaffin ist (idR. mit dem MainThread)

TBitmap gehört eindeutig zur Kategorie ganz blöd.

Wenn jemand so etwas in einem Thread verwendet und keine Probleme damit hat, dann jeden Abend das in das Nachtgebet mit einschliessen und weiter hoffen. Es ist keine zugesicherte Eigenschaft und läuft wohl eher durch Zufall (oder man hat sich irgendwo durch die Hintertür eine Synchronisation eingefangen). Anyway, empfehlen würde ich es nicht und darauf bauen erst recht nicht.

Aber eine Hummel kann eigentlich auch nicht fliegen und tut es trotzdem, weil ihr die Physik und Aerodynamik fremd und sowas von egal sind.

[Rollo62]

Zitat:

D.h. wenn du dein Bitmap nur in einem Thread erzeugst, bearbeitest und freigibst ist alles gut.

Zitat:

wo das Canvas her kommt

Könnte es sein das Beides stimmt ?

Wenn man nur das BMP im Speicher anlegt und über Scanline auf die Pixel zugreift ist es im Thread machbar,
sobald ein Canvas oder was anderes in Spiel kommt ist es MainThread affin ?

Ich halte es so das ich nur im Mainthread drauf zugreife, weil mir diese Aussagen auch nicht 100% sicher sind.

Rollo

[Sir Rufo]

@Rollo62

Es gibt keine konkrete Aussage darüber, was man von TBitmap gefahrlos im Thread verwenden kann und was nicht - es hat beim Klassendesign keinen interessiert.

Zugesichert wird nur das korrekte Verhalten im MainThread.

Den Rest muss man sich durch SourceCode-Wälzen zusammensuchen. Einfaches Ausprobieren reicht da leider nicht aus, denn eine race condition macht sich meist erst dann bemerkbar, wenn man gerade nicht hinschaut (Murphys Law)

[Kraisel]

Kategorie "ganz blöd" kannte ich noch nicht, aber sofort in mein Repertoire aufgenommen.

Wenn es unbedingt parallel sein muss, geht es so:

1) MainThread: Kopie einer Bmp in ein allociertes Memory, das geht sau schnell, wenn man das Memory genau wie die Bmp organisiert.
2) SomeThread: Manipulieren des Memories, vielleicht den alten Brasenham-Algorithmus wieder aus dem Keller holen. Aber bitte an den Rändern richtig clippen. Sonst gibt es Überraschungen.
3) MainThread: Kopie des Memories zurück in die Bmp, das geht wieder schnell.

So mache ich z.B. 3D - Rotationen (ohne die 3D-Engine vom System) mit mehreren Threads gleichzeitig. Das funktioniert einwandfrei. Man muss nur schmerzfrei bleiben, bis alles läuft.

Für viele Aufgaben, die man hat, kann man ja eine eigene TcMemBmp-Class bauen. Bilder abdunkeln, aufhellen, oder sogar Linien zeichnen ist ja trivial. Benötigt man aber den gesamten Comfort des Canvas oder will rendern, sollte man wohl besser im MainThread bleiben.

Wahrscheinlich könnte man auch eine dll schreiben, die nichts anderes macht, als Bitmaps zeichnen. Aber das ist irgendwie auch "ganz blöd".

[Kraisel]

Vielleicht kann man aber folgendes machen:

1) MainThread: Bmp.map aufrufen.
2) SomeThread: Direktes Manipulieren der TBitmapData.Data.
3) MainThread: Bmp.unmap aufrufen.

Das müsste ja OK sein, solange der MainThread die Bmp nicht anrührt, bis die Threads fertig sind. Oder?

[BUG]

Zitat von Kraisel:

Oder?

Disclaimer: Ich hab keinen Einblick wie das genau implementiert ist.

Wenn der Mainthread mit einem blanken Zeiger auf den Daten herumholzen kann, sollte das der Hilfsthread auch können. Denke aber daran, dass der Ablauf dann richtig synchronisiert werden muss.