2dimensionales Array zu Pointer für Thread und Zugriff

[BAMatze]

Hallo noch mal an alle und gesundes Neues Jahr,

Ich hab eine Frage für den Pointer eines 2 Dimensionalen dynamischen Arrays den ich an ein Thread übergeben möchte und wie ich damit arbeiten kann. Ich weiß wenn ich ein Array erstelle ala

Delphi-Quellcode:

  MyArray: array of array of integer;

dann sollte nach meinen Kenntnissen MyArray an sich gleich einen Pointer darstellen. Wenn ich diesen jetzt über:

Delphi-Quellcode:

  Threadhandle := CreateThread(nil, 0, @ThreadWelt, Welt, 0, TreadID);

an mein Thread übergebe, könnte ich mir vorstellen, dass es funktioniert (bin mir aber vieleicht zu 20% sicher). Jetzt die eigentliche Frage, wie kann ich jetzt in meinem Thread darauf zugreifen? Ich habe gesehen, dass andere Speicher allochieren für ihre Pointer (bisher aber nur für einfache Variablen gesehen). Hoffe jemand kann mir einen Gedankenanstoß geben, für den Punkt an dem ich mich jetzt befinde.

[Uwe Raabe]

Der Zusammenhang zwischen "MyArray" und "Welt" geht aus deinem Post nicht so ganz hervor...

Und: Warum verwendest du CreateThread und nicht die vorhandene Thread-Klasse? Da wäre vieles einfacher und mit Pointern muss man sich da auch nicht rumschlagen, wenn man nicht möchte.

[BAMatze]

Du hast ja auch schon auf mein anderen Thread geantwortet. Welt stellt das 2dimensionale Array dar. Die Indizes sind die "Koordinaten". Könntest du mal ein kurzes Beispiel geben, wie man mir dem TThread arbeitet? Ich lese mir seid heute morgen Berichte über das Thema durch und bin noch nicht sehr viel schlauer geworden.

Danke

[Klaus01]

Hallo,

so könnte das Grundgerüst Deiner Threadklasse ausschauen:

Delphi-Quellcode:

 
TDeinThread = class(TTHread)
  private
    // Thread variable
  protected
    procedure execute;override;
  public
    constructor create(init Parameter);
end;

Delphi-Quellcode:

constructor TDeinThread.create(init Parameter);
begin
  inherited create(false);
  // mache etwas mit den init Parametern
end;

Delphi-Quellcode:

procedure TDeinThread.execute;
begin
  while not terminated do
    begin
      // do some work
    end;
end;

.. aber ich denke nicht, dass Deine Simulation mit einem Thread schneller laufen wird.
Warum, Dein Programm hat quasi nur eine Aufgabe die "Lebewesen" über das Bitmap zu bewegen.
Aus meiner Sicht macht es hier dann wenig Sinn das in einen Thread auszulagern.

Grüße
Klaus

[Uwe Raabe]

Wenn es um deine Simulation geht, glaube ich auch, daß du dir mit einem Thread das Leben nur unötig schwer machst. Schneller wird deine Anwendung damit sicher nicht.

[BAMatze]

Hmm da hast du natürlich schon recht. Wobei jetzt eigentlich schon 2 Komponenten in dem Programm derzeit nacheinander ablaufen. Es wird die "Umwelt" verändert (das heißt Wasser und Nahrung wird hinzu gefügt) und die Lebewesen werden gesetzt. Du hast natürlich Recht, dass dabei die Berechnung der derzeitigen "Lebewesen" die meiste Rechenzeit verschlingt. Das Ziel soll ja eigentlich sein, eine 2. Lebensform hinzuzufürgen, die sich von der jetztigen ernährt und dann zu schauen, wie sich die Anzahlen der beiden Lebensformen verändern. Also muss nochmal soviel Rechenzeit verwendet werden. ICh weiß ich muss dafür sicherlich die Anzahl der "Lebensformen" insgesamt warscheinlich beschränken, Die Zyklen der Erneuerung der Welt und der Bewegungen der Lebewesen müssen angepasst werden, es muss sicherlich auch ein vieleicht sogar minutenlanges Intevall für die Gesamtberechnung vorgegeben werden, ...
Ich hoffe mit der Auslagerung der einzelnen Berechnungen (1. Thread = Welt, 2. Thread = Lebensform1, 3. Thread = Lebensform2) in die unterschiedlichen Threads kann ich eine Verbesserung der Rechnerperformence.
Vieleicht gibt es dafür ja auch noch andere Möglichkeiten. Bin für Vorschläge immer offen.

Danke

[Klaus01]

.. beachte dann aber bitte das die GUI nicht threadsafe ist.
Auf GUI Elemente solltest/mußt Du mit synchronize zugreifen.

Grüße
Klaus

[Uwe Raabe]

Die Anzahl der Berechnungen kannst du mit drei Threads nicht reduzieren. Mehr noch wird das ganze System langsamer laufen. da die einzelnen Threads auf gemeinsame Daten zugreifen und diese Zugriffe gegenseitig synchronisiert werden müssen. Ich bleibe dabei: mach alles im Hauptthread und du kommst besser dabei weg und wahrscheinlich schneller zum Ziel.

[BAMatze]

Also eigentlich greifen sie nur auf unterschiedlich Daten zu. Einmal gibt es einen Type-Strukt für die einzelnen Punkte auf der "Welt" dieser wird im 1. Thread geändert. Der 2.Type-Strukt enthält die Daten für die erste Lebensform dieser werden im 2. Thread geändert. Und für den 3. Type-Strukt und dem 3. Thread gilt das gleiche, wie bei den ersten beiden. Am Ende werden dann alle Daten zusammen gefügt. Und im letzten Schritt wird das alles komplett (Hauptthread) darzustellen. und bisher wird alles hintereinander berechnet.

[Uwe Raabe]

Zitat:

Zitat von BAMatze

Also eigentlich greifen sie nur auf unterschiedlich Daten zu. Einmal gibt es einen Type-Strukt für die einzelnen Punkte auf der "Welt" dieser wird im 1. Thread geändert. Der 2.Type-Strukt enthält die Daten für die erste Lebensform dieser werden im 2. Thread geändert. Und für den 3. Type-Strukt und dem 3. Thread gilt das gleiche, wie bei den ersten beiden.

Soweit ich mich erinnere, verwendet die 1. Lebensform die Welt, um sich zu ernähren - damit hast du schon mal Zugriffe aus zwei Threads auf die Welt. Wenn sich die 2. Lebensform von der ersten ernährt, hast du selbiges. Ergo: die Zugriffe auf Welt und 1. Lebensform müssen gegenseitig synchronisiert werden.

Beispiel:
Welt_aendern erhöht die Nahrung an einem Ort. Währenddessen nimmt Lebensform 1 Nahrung von diesem Ort auf. Bei zwei Threads kann dir folgendes passieren:

a)
Thread1: Welt[i,j].iNahrung := Welt[i,j].iNahrung + random(3);
Thread2: Objekt.iNahrung := Objekt.iNahrung + Welt[Objekt.ix-1,Objekt.iy-1].iNahrung;
Thread2: Welt[Objekt.ix-1,Objekt.iy-1].iNahrung := 0;

b)
Thread2: Objekt.iNahrung := Objekt.iNahrung + Welt[Objekt.ix-1,Objekt.iy-1].iNahrung;
Thread1: Welt[i,j].iNahrung := Welt[i,j].iNahrung + random(3);
Thread2: Welt[Objekt.ix-1,Objekt.iy-1].iNahrung := 0;

c)
Thread2: Objekt.iNahrung := Objekt.iNahrung + Welt[Objekt.ix-1,Objekt.iy-1].iNahrung;
Thread2: Welt[Objekt.ix-1,Objekt.iy-1].iNahrung := 0;
Thread1: Welt[i,j].iNahrung := Welt[i,j].iNahrung + random(3);

Je nach Thread-Umschaltung bekommst du ein anderes Ergebnis. Im Fall b) verschwindet sogar Nahrung. Dieses Beispiel mag vielleicht nicht so schwere Folgen haben, aber es zeigt doch die Problematik auf.

Zitat:

Zitat von BAMatze

Am Ende werden dann alle Daten zusammen gefügt. Und im letzten Schritt wird das alles komplett (Hauptthread) darzustellen.

Der Hauptthread kann erst mit der Darstellung beginnen, wenn alle anderen Threads mit ihren Berechnungen fertig sind. Zwischenzeitlich tut er so gut wie nichts. Während der Darstellung dürfen die anderen Threads aber nichts mehr an den Daten ändern. Du must den Zugriff also auch hier synchronisieren.

Zitat:

Zitat von BAMatze

und bisher wird alles hintereinander berechnet.

Auf einem 1-Prozessorsystem wird auch alles hintereinander berechnet, nur nicht in der gleichen Reihenfolge. Der Overhead für die Thread-Umschaltung erhöht die gesamte Laufzeit allerdings. Du kannst also theoretisch nur dann an Laufzeit gewinnen, wenn mindestenes zwei Prozessoren gleichzeitig an deiner Simulation werkeln und der Overhead diesen Vorteil nicht auffrisst.

Ich bin grundsätzlich ein Freund von Threads, verwende sie aber meistens nur um die Berechnungen von der GUI zu trennen, damit die Anwendung auch noich bedienbar bleibt. Meistens erhält man damit auch eine einfache Möglichkeit, die Berechnung vorzeitig zu beenden.

Wenn schon Threads, dann wäre mein Vorschlag: Die gesamte Simulation in der Execute-Methode eines abgeleiteten TThread-Objekts zu verfrachten, für die Ausgabe werden in besteimmten Zeitabständen Bitmaps gemalt. Der Zugriff auf die Bitmap vom Hintergrund- und Hauptthread wird über ein geeignetes Objekt synchronisiert (z.B. CriticalSection). Die Aktualisierung des Treeviews würde ich komplett rausnehmen, da diese bei entsprechend vielen Elementen gehörig in die Knie geht. Für die verwendete Art der Darstellung täte es übrigens auch ein TMemo.