Zitat von himitsu:

aber beim Freigeben oder Ändern kann, je Gruppe, natürlich immer nur einer gleichzeitig, wenn die Speicher zufällig im selben Block liegen.

Das ist das Schöne an einer Lösung, wo man für eine konkrete Klasse noch einen Pool dazwischenschalten kann: Ich kann jedes Objekt in jeden Pool stecken, praktisch also auch ganz schnell in meinen Thread-lokalen.

Zitat von BUG:

Zitat von himitsu:

aber beim Freigeben oder Ändern kann, je Gruppe, natürlich immer nur einer gleichzeitig, wenn die Speicher zufällig im selben Block liegen.

Das ist das Schöne an einer Lösung, wo man für eine konkrete Klasse noch einen Pool dazwischenschalten kann: Ich kann jedes Objekt in jeden Pool stecken, praktisch also auch ganz schnell in meinen Thread-lokalen.

Das würde Daniel aber auch nix helfen, die Instanzen gibts schon, die dann noch irgendwo in nem Pool zu verschieben, würde die Sache kaum schneller machen.

Es gibt gewisse Dinge, die kann man ebend nicht mit multithreading schneller machen (manchmal geht das sogar eher nach hinten los).
ScaleMM und Co mögen schneller sein, wenn man innerhalb mehrerer Threads Instanzen erzeugt und wieder freigibt oder mit strings hantiert (siehe Benchmarks) . Aber einmal erstellte Instanzen parallel freigeben, geht auch dort nicht schneller (eher langsamer wie auch meine Tests bestätigen).

Ich hab' mich jetzt eh an anderer Stelle im Projekt verfuddelt. Da hilft alles nix mehr.

Threads 1..4 bauen die Datenstruktur auf, Threads 5 und 6 solchen selbige durchsuchen, wenn die ersten vier Threads fertig sind. In der Theorie simpel, in der Praxis ein Deadlock. Ich glaub' das geht grundsätzlich nicht. *g*

Zitat von Daniel:

Ich hab' mich jetzt eh an anderer Stelle im Projekt verfuddelt. Da hilft alles nix mehr.

Threads 1..4 bauen die Datenstruktur auf, Threads 5 und 6 solchen selbige durchsuchen, wenn die ersten vier Threads fertig sind. In der Theorie simpel, in der Praxis ein Deadlock. Ich glaub' das geht grundsätzlich nicht. *g*

Ach was, alles ganz einfach mit der PPL!
Wo genau lockts denn? Grundsätzlich sollten ja für den start von Task 5 und 6 die ersten 4 fertig sind. Also können nur entweder die ersten 4 sich gegenseitig locken oder 5 und 6.

Das Projekt sollte auch noch für XE4 kompatibel bleiben, daher nutze ich ganz klassisch TThread.
Jetzt eben das war ein unglücklicher Copy&Paste-Fehler aus der Rubrik "Ich probier mal eben was aus.".

Ich würde mal schauen, ob Du dir nicht einen eigenen Speichermanager für deine Objekte schreibst. Dem gibst Du einen Block an Speicher und wenn Du deine neuen Objekte bauen willst, dann dann musst Du gar nichts freigeben. Der Block muss halt nur groß genug sein (der Einfachheit halber). Alternativ kann er auch mehrere Blöcke verwalten. Der ist der einzige, der Speicher wirklich anfordert. Deine Sonderobjekte holen sich ihren Speicher von deinem MM.

Wenn deine Objekte nur aufgebaut werden, aber sonst nicht großartig leben, d.h. freigegeben, neu aufgebaut etc. sollte das doch kein Problem sein:

zusammenfalten · markieren

Delphi-Quellcode:

function TMyMM.GetMem (size : Integer) : Pointer;
Begin
  if NextFreeByte+size > maxSizeAvail then
    raise EOutOfMemory.Create; // oder neuen Block anfordern
 
  result := @MyMemoryBlockAsByteArray[NextFreeByte];
  inc (NextFreeByte, size);
end;

function TMyMM.Dispose (p : Pointer; size : Integer);
Begin
  // WTF;
End;

Procedure TMyMM.ClearMemory;
Begin
  NextFreeByte := 0;
End;

Wenn Du deine Objekte dann neu aufbauen willst, Rufst Du ClearMemory auf und fertig ist die Laube. Klar, ist nicht gerade Speicheroptimal, wenn Dispose öfter aufgerufen wird, aber ich sagte eingangs ja: Wenn...

Zitat von Stevie:

Das würde Daniel aber auch nix helfen, die Instanzen gibts schon, die dann noch irgendwo in nem Pool zu verschieben, würde die Sache kaum schneller machen.

Die Datenstruktur wird wiederholt freigegeben und wieder neu aufgebaut. Wenn man bei der Freigabe, anstelle sich um ein Lock zu kloppen, die Instanz lokal merken kann, könnte das schon was bringen.

Zitat von Daniel:

Threads 1..4 bauen die Datenstruktur auf, Threads 5 und 6 solchen selbige durchsuchen, wenn die ersten vier Threads fertig sind.

Ein großer Baum, der öfter mal neu erstellt wird und ansonsten von 2 Threads durchsucht wird ... klingt nach einer spannenden Anwendung

@Daniel

Du brauchst dazu 7 Threads

Thread 1

• Startet 4 Holt-mal-Daten Threads und wartet bis die fertig sind
• Fasst die Ergebnislisten zusammen / teilt die Ergebnisse für die Such-Threads auf
• Startet 2 Sucht-mal-Daten Threads und wartet bis die fertig sind
• Beendet sich (oder legt sich schlafen)

Macht in Summe 7 Threads und du brauchst somit (aus der Sicht der Anwendung) nur mit einem Thread jonglieren.

Klingt wie ein Fall für die Pipeline der OmniThreadLibrary.