Multithreading Systemressourcen erschöpft

[wangxuebing]

Hallo,

ich arbeite an einem Programm, das verschiedene Bilder bearbeitet. Zur Beschleunigung wollte ich Threads verwenden. Leider bekomme ich dabei die Fehlermeldung "Systemressourcen erschöpft", was ich mir nicht so ganz erklären kann (64bit System, 16GB RAM, 8 Kerne)
Der Code sieht grob folgendermaßen aus:

Code:

procedure MyThread.Execute();
var
  BMP1, BMP2 : TBitMap;
  i, j : Integer;
begin
  BMP1.Create;
  BMP2.Create;
  for i := LOW to HIGH do
  begin
    for j := LOW to HIGH do
    begin

    Berechne(x1, y1, x2, y2, PosX1, PosY1, PosX2, PosY2);

    BMP1.Setsize(x1,y1);
    BitBlt(BMP1, 0, 0, BMP1.width, BMP1.height, ThreadBMP, PosX1, PosY1);

    BMP2.Setsize(x2,y2);
    BitBlt(BMP2, 0, 0, BMP2.width, BMP2.height, ThreadBMP, PosX2, PosY2);

    /// vergleiche BMP1 und BMP2

    BMP1.SaveToFile(Filename);

    end;
  end;

  BMP2.Free;
  BMP1.Free;
end;

Die ThreadBMP ist eine private TBitMap vom Thread und wird beim create des Threads geladen (jeder Thread lädt eine andere Datei). LOW und HIGH sind feste Werte, die ich vorher schon berechnet habe.
Das Programm stürzt mal bei "SetSize()" und mal bei "SaveToFile" mit oben genannter Fehlermeldung ab.

Hat jemand eine Idee woran das liegen könnte?
Ich befürchte ja, dass es an den TBitMap liegt, aber jeder Thread hat ja seine eigenen lokalen Bitmaps und somit sollten sich die Threads eigentlich nicht in die Quere kommen...

Danke für eure Hilfe,
WXB

[Klaus01]

Hallo,

mache mal aus:

Delphi-Quellcode:

BMP1.Create;
BMP2.Create;

Delphi-Quellcode:

BMP1 := TBitmap.create;
BMP2 := TBitmap.create;

edit:

und vielleicht noch alles in try .. finally .. end einpacken

Grüße
Klaus

[Bummi]

siehe Klaus
+ BitBlt Bezieht sich auf ein canvas.Handle
+ Resourcenschutz

[wangxuebing]

Sorry, hatte mich verschrieben. Meinte natürlich BMP1 := TBitMap.Create; und auch das BitBlt ist mit Canvas.Handle (hatte nur keine Lust, alles hinzuschrieben ;-) )
Mit einem Thread läufts auch wunderbar durch... Nur ab 2 Threads mag es nimmer...

@Bummi: Wie meinst du das mit dem Ressourcenschutz?

[Daniel Schuhmann]

Zitat:

Zitat von wangxuebing (Beitrag 1169563)

Wie meinst du das mit dem Ressourcenschutz?

http://www.delphi-treff.de/tutorials...schutzbloecke/

[Klaus01]

Hallo,

Ist BitBlt thread safe?

Der Canvas ist meines Erachtens nicht Thread safe.

Resource Schutzblock:

Delphi-Quellcode:

inst := TInst.create
try
  //tu etwas mit inst
finally
  inst.free
end;

Grüße
Klaus

[wangxuebing]

Hab grad alles was der Thread macht in Try...finally..end; gepackt. Bringt aber keine Veränderung.
Macht das dem BitBlt was aus, wenn es von einem lokalen Bild etwas in ein anderes lokales Bild in zwei verschiedenen Threads malt?
Bei gleicher Source oder Destination würd ich das ja verstehen, aber wenn die doch lokal im Thread definiert/erzeugt werden...

[Klaus01]

BitBlt ist aber eine Systemfunktion - oder..

Hier findest Du ein Beispiel wie Du BitBlt thread safe verwenden kannst.

BitBlt benötigt GDI resourcen (die sind nicht unbegrenzt verfügbar) - aber bei zwei aktiven Threads sollte das noch kein Problem darstellen.

Grüße
Klaus

[wangxuebing]

Gibts ne Möglichkeit das Bitmap nicht im Graphikkartenspeicher sondern im Arbeitsspeicher zu halten? Weil davon sollte ich genug haben (50% frei laut Ressourcenmonitor).

[himitsu]

Das liegt doch im Arbeitsspeicher?


Höchstens wenn man es anzeigt liegt zusätzlich noch etwas davon (eine Kopie) im Grafikspeicher, aber das sollte dort nicht auffallen.

[Bummi]

Resourcen bedeutet nach meiner Erfahrung meist Handles nicht Arbeitsspeicher

[wangxuebing]

Da ich recht große Bilder bearbeite fällt es dort eventuell doch auf. Aber ich zeig die Bilder nicht an, sondern bearbeite sie eigentlich nur.

@Klaus01: Danke für das Beispiel, leider hab ich 0 Ahnung, wie ich das in meinen Code einbauen soll :-(

Hab jetzt mal versucht, das Bitblt in eine CriticalSection zu stecken, aber auch das schlägt fehl... (8 Threads)

[NickelM]

try...finally fürt das auch was nach finally und dem dazugehörenden end ist trotzdem aus, auch wenn Fehler bei dem Code zwischen try und finally gibt. Es scheint so, dass es zu zu Fehlern kommt, beim Ausführen deines Codes, bzw. es liegt zuviel gleichzeitig im Speicher, und da du es erst beim ERFOLGREICHEN BEENDEN freigibts und es bei Fehlern der Thread abstürtzt aber die Instanzen nicht freigeben werden, liegen die immernoch im Speicher. Baue das ganze mal so um:

Delphi-Quellcode:

procedure MyThread.Execute();
var
  BMP1, BMP2 : TBitMap;
  i, j : Integer;
begin
  BMP1 := TBitMap.Create;
  BMP2 := TBitMap.Create;
  try //hier anfangen, weil ja das Berechnen anfängt, am besten immer nach dem Create machen
    for i := LOW to HIGH do
    begin
      for j := LOW to HIGH do
      begin

        Berechne(x1, y1, x2, y2, PosX1, PosY1, PosX2, PosY2); //Erklär auchz mal hier, was er im groben macht
        If ThreadBMP <> nil then //Baue das ein, falls du einen Try...finally Block auch im Create von dieser Instanz einbaust...
        begin
          BMP1.Setsize(x1,y1);
          BitBlt(BMP1.Canvas.Handle, 0, 0, BMP1.width, BMP1.height, ThreadBMP, PosX1, PosY1);

          BMP2.Setsize(x2,y2);
          BitBlt(BMP2.Canvas.Handle, 0, 0, BMP2.width, BMP2.height, ThreadBMP, PosX2, PosY2);
        end;

        /// vergleiche BMP1 und BMP2 //was macht er da im groben? Bitte auch mal erklären

        BMP1.SaveToFile(Filename);
      end;
    end;
  finally
    BMP2.Free;
    BMP1.Free;
    ThreadBMP.Free; //Du machst doch nach nichts mehr mit der Instanze oder?
  end;
end;

Mach das mit try...finally auch mal bei ThreadBMP, falls du direkt nach dme Create noch was machst

P.S. : CriticalSection brauchst du nur, wenn du eine globale Variable hast, worauf von mehren Threads gleichzeitig zugegriefen werden können. Verwendet man z.b. bei Log-Dateien, wie von Hauptthread sowie von anderen Threads beschrieben werden.
Zu dem was Klaus meint, ist da du eine Win32bit-Anwendung schreibst (wenn nicht müsstest du mal falls du XE2 hast, mal die Anwendung auf 64bit umstellen, dann hast du deine vollen 16GB-Speicher verwenden.
Bei einer Win32-Anwendung kannst du nur maximal rund 3,2GB-Ram verwenden, wegen 32bit (4Bytes für Pointer; Gug doch mal, den Typ Cardinal an. Das ist ein Typ von 0..bis rund 3.200.000.000.
Das ist wiederum der maximale Wert eine Pointers(Zeiger) in einer 32bit-Anwendung. Also der Bereich auf den deine Anwendung zugreifen kann also "zeigen" kann, da der Pointer halt nur eine Größe von 4 Bytes haben kann :-D.

[Medium]

Vergiss auf jeden Fall die "Grafikspeicher"-Sache. Wie schon gesagt wurde, landen Bitmaps im RAM. Grafikspeicher kommt für (zunächst) nur 2 prinzipielle Fälle zur Anwendung: Das tatsächlich auf dem/der Monitor/en angezeigte Bild (in der Regel fix und nur von der eingestellten Auflösung+Farbtiefe im System abhängig), und für Texturen und andere Resourcen sowie ggf. Stückchen Shadercode im Zusammenhang mit 3D-APIs (Direct3D, OpenGL).

Die Fehlermeldung die du bekommst, liest sich eher wie "GDI-Resourcen verbraucht". Die GDI (Graphics Device Interface; (ein mögliches aber von Delphi/VCL üblicherweise genutztes) Grafik-Subsystem von Windows) hat Einschränkungen, die sich nicht unmittelbar an RAM, Grafikspeicher oder CPU messen, sondern so einfach in Windows existieren.

Wie groß sind deine Bitmaps so im Schnitt?

[Sir Rufo]

Zitat:

Zitat von wangxuebing (Beitrag 1169556)

64bit System, 16GB RAM, 8 Kerne

Ich hoffe ja mal, dass du auch Delphi XE2 benutzt und ein x64 Projekt, denn sonst kannst du eh nur mit max. 2GB für die Anwendung rechnen.

[himitsu]

Zitat:

Zitat von Sir Rufo (Beitrag 1169635)

denn sonst kannst du eh nur mit max. 2GB für die Anwendung rechnen.

Durchschnittlich maximal 0,5 GB pro Bitmap für einen Thread á 2 Bitmaps.
(bei mehr Threads verringert es sich dann natürlich)

[BUG]

Zitat:

Zitat von himitsu (Beitrag 1169644)

Durchschnittlich maximal 0,5 GB pro Bitmap für einen Thread á 2 Bitmaps.
(bei mehr Threads verringert es sich dann natürlich)

Aber > 100MB-Bilder muss man auch als Bitmap auch erst einmal haben.
Ich habe gerade mal testweise ein 4000x3000-Pixel-Bild (-> 12 Megapixel) als Bitmap gespeichert und kam auf 34 MB.

[himitsu]

Ich hatte letztens mal einen Screenschot von Win7 gemacht, mit 8 Bildschirmen ... ergab ein 54 MB PNG.
(irgendwie scheint sich dort irgendwann die Komprimierung zu verabschieden, denn das Bitmap war ein paar Kilo kleiner)

Und ich hatte mal einen hochauflösende Scan, der war schon geviertelt und dennoch waren die JPegs jeweils schon knapp über 100 MB.


Man muß halt bedenken, daß die Bitmapdaten als ein zusammenhängender Block im RAM liegen und Speicher kreuz und quer reserviert wird und überall auch noch EXE- und DLL-Images rumschwirren, ist es schon schwer in 32 Bit noch ein passendes freies fleckchen zu finden.

8 Threads á 2 Bilder mit je nur 50 MB sind auch schon über 800 MB ... knapp 50% des anfänglich freien Speichers, aber ob da dann auch noch ausreichend große zusammenhängende Blöcke verfügbar sind...

Zitat:

Wie groß sind deine Bitmaps so im Schnitt?

[wangxuebing]

Programm läuft auf 64bit. Ein Bild hat 8200x8200 Pixel und ist ein bmp (64MB).

[SirThornberry]

Zitat:

Ein Bild hat 8200x8200 Pixel und ist ein bmp (64MB).

Haben deine Bilder nur 8Bit Farbtiefe?
8200 x 8200 = 67240000 Bildpunkte
Wenn jeder Bildpunkt 3 Byte hätte (24Bit) wären das bereits 192 MB.

[himitsu]

Zitat:

Zitat von wangxuebing (Beitrag 1169682)

Programm läuft auf 64bit.

Nur auf einem 64 Bit-Windows oder ist es wirklich ein 64 Bit-Prozess. (Delphi XE2 mit Win64 als Ziel)