Multithreading Systemressourcen erschöpft

[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 .

[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 von wangxuebing:

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 von Sir Rufo:

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 von himitsu:

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.