Zitat von Michael_Bayer:

Hmm..würde das so funktionieren, dass ich ein globales Array aufbaue und dem Thread mitgebe, er soll in Array[1] die Lösung stecken, wenn er fertig ist?

Ja, aber nicht ohne Exclusion-Objects (s.o.). Bzw. wenn es ein Integerarray ist, kannst du die Interlocked*-Funktionen verwenden.

Zitat von Michael_Bayer:

Oder nochbesser: Kann ich dem Thread sagen, es soll die Lösung in eine Procedure als Parameter übergeben, und die Procedure ändert dann die VCL?

Da du diese Prozedur ja vom 2. Thread aus aufzurufen scheinst kann das keine Lösung sein. Denn die Prozedur läuft dann im Kontext dieses Threads.

Zitat von Michael_Bayer:

Oder muss ich das so machen, dass ich eine globale Variable Editable mache, die ich auf false setze, wenn ein Thread gerade ein VCL-Element ändert?

Selbst das ist nur mit Interlocked*-Funktionen sicher, da ansonsten ein Thread die Variable auslesen könnte, obwohl du in einem anderen schon "Bla := False" gesagt hast. Wohlgemerkt, das ist hypothetisch (in der Praxis wird es auf einem Uniprocessor-System quasi nie zu Problemen kommen).

Versuchen wir mal die Vorstellungskraft zu forcieren (ein besseres Beispiel fiel mir nicht ein):

Stell dir den Code (jede Seite ein Zeitscheibenintervall ausgeführten Codes) als ein Buch vor und die Daten (jede Seite eine beliebige komplexe Datenstruktur - eine Datenstruktur kann natürlich auch mehrere Seiten umfassen) als ein anderes.
Hast du einen Prozessor, so kann im Codebuch nur eine Seite gleichzeitig aufgeschlagen sein. Bei mehreren Prozessoren entspricht die maximale Anzahl gleichzeitig aufgeschlagener ("ausgeführter") Seiten der Anzahl Prozessoren. Nun ist es so, daß in dem Datenbuch auch mehrere Seiten existieren. Eine Seite stellt dabei eine komplexe Datenstruktur dar.
Da wir aber mit mehreren parallelen oder quasi-parallelen Threads arbeiten, kann es passieren, das Thread#1 auf Seite#1 schreibt. Nun sagt das Zeitscheibenprinzip, daß Thread#1 irgendwann eingefroren wird und Thread#2 an der Reihe ist. Leider passiert aber das Einfrieren, während Thread#1 nur etwa 1/3 der Seite#1 geschrieben hat. Thread#2 ist nun also an der Reihe. Da Thread#2 auch an Seite#1 interessiert ist, versucht es dorthin zu schreiben - natürlich vom Anfang der Seite#1. Da Thread#2 etwas optimaler kodiert ist, kann Thread#2 vor dem Einfrieren ganze 50% der Datenstruktur schreiben. Nun ist Thread#3 an der Stelle, welcher die Daten aus Seite#1 gern auslesen möchte. Tut er auch. Nun die Quizfrage: was steht auf Seite#1? Was steht nach einem 2ten Durchgang auf Seite#1? Ist dies das gewünschte Verhalten?

Nun kannst du dir ein Ausschlußobjekt so vorstellen, daß Thread#2 und #3 zwar an die Reihe kommen, jedoch sehen, daß Seite#1 gerade beschrieben wird. Deshalb warten Sie weiter und geben die Kontrolle direkt wieder ab. Statt Threads kannst du auch Prozesse annehmen und statt einer Buchseite eine einzelne Datei - aber bei Dateien gibt es andere Ausschlußmechanismen.

nebenbei bemerkt: Ich hätt da oben ein kleines Problem

Zitat von Helmi:

nebenbei bemerkt: Ich hätt da oben ein kleines Problem

Ich weiß ...

Zitat von Helmi:

kann man das so lassen oder gibts was auszusetzen?

Ja gibt es. Man kann alles so lassen, nur korrekt ist es eben nicht ... meine Antwort über deiner Frage:

Zitat von Helmi:

nebenbei bemerkt: Ich hätt da oben ein kleines Problem

...sollte dir Auskunft geben was falsch ist.

Übrigens: Synchronize() führt den Code im Hauptthread des Prozesses aus (zumindest war dies mindestens bis Delphi 5 so). TThread ist eigentlich relativ ungeeignet für Multithread-Anwendungen. Allerdings ist die VCL mindestens bis Delphi 6 auch nicht multithread-safe gewesen ... die aktuellen Versionen kenne ich nicht. Es gibt ja aber auch noch F1

aber ich hab doch nur einen Thread und keine Multi-thread-Anwendung

und wie mach ich das mit der ListView?
wie erzeug ich sie wo am besten auf?

Häh?
Ich sehe doch da ein TThread-abgeleitetes Objekt in deinem Code? Dir ist schon bewußt, daß jeder Prozess mindestens einen (Haupt-)Thread hat? Wieviel hat dein Prozess, wenn du noch einen hinzufügst? Würdest du deine Behauptung, daß 2 Threads nicht multi-threaded sind noch aufrecht erhalten wollen?

ist ja alles schön und recht das mit dem Multi-Threads ja oder nein

aber ich wollt das eigentlich alles ned wissen

Ich wollt nur das mit der ListView wissen

irgendwie werden gerade zwei themen zusammen geschmissen, die normalerweise zwei (DP-)Threads sind.

Bleiben wir bitte nur bei einem Thema - also der ListView

Zitat von Helpmi:

irgendwie werden gerade zwei themen zusammen geschmissen, die normalerweise zwei (DP-)Threads sind.

Nein werden sie nicht, denn das Updaten von VCL-Elementen (z.B. deinem ListView) in einem separaten Thread ist ganz simpel: ziemlich gefährlich.

und wie dann?

der einer sagt: ja, es geht, der andere sagt: nein - zu gefährlich

was jetzt?

Zitat von Helmi:

und wie dann?

der einer sagt: ja, es geht, der andere sagt: nein - zu gefährlich

was jetzt?

Ja es geht (wär ja blöd, wenn nicht) - jedoch sind bestimmte Regeln zu beachten. (s.o.)

Also wie ich das verstanden habe, muss man vor dem kritischen Bereich (dem Ändern eines VCL-Objektes) die "critical section" "entern" und danach wieder "leaven".
Meine Frage nun: Wenn ich die critical section betrete, woher wissen dann die anderen Threads, welches Objekt sie nicht anfassen dürfen? (Dass die Threads dann komplett stillstehen, kann ja nicht sein)

EDIT: Ahhhh verstanden - Wenn ich eine CriticalSection betrete, dann bin nur ich darin und alle, die auch etwas "kritisches" machen wollen, müssen warten.
So muss ich überall, wo etwas zusammenhauen könnte, die CriticalSection benutzen.

Allerdings kommt mir das etwas.. naja.. ineffektiv vor.
Ich muss ja dann auch bei Leseoperationen auf ein Objekt, dass woanders geschrieben werden könnte, eine CriticalSection benutzen - so werden ja auch Leseoperationen serialisiert...muss das sein?

EDIT2: Aber das Problem könnte ich ja minimieren, wenn ich für JEDES Objekt eine eigene CriticalSection erstelle. So sitze ich dann zum Schluss vielleicht mit 20 CS rum, aber gehen sollte das. (Gibts eine logische Grenze für CriticalSections?)

Zitat von Michael_Bayer:

Also wie ich das verstanden habe, muss man vor dem kritischen Bereich (dem Ändern eines VCL-Objektes) die "critical section" "entern" und danach wieder "leaven".
Meine Frage nun: Wenn ich die critical section betrete, woher wissen dann die anderen Threads, welches Objekt sie nicht anfassen dürfen? (Dass die Threads dann komplett stillstehen, kann ja nicht sein)

Ganz einfach. Jeder Thread der auf ein bestimmtes Objekt (sei es ein Integer, ein Array oder ein String) zugreift, sollte vorher in die Critical Section gehen. Der Code danach sollte IMMER in einem try-finally-Block stehen, damit die CritSect auch verlassen wird!

Zitat von Michael_Bayer:

EDIT: Ahhhh verstanden - Wenn ich eine CriticalSection betrete, dann bin nur ich darin und alle, die auch etwas "kritisches" machen wollen, müssen warten.
So muss ich überall, wo etwas zusammenhauen könnte, die CriticalSection benutzen.

Exakt. Und sobald du ein weiteres Objekt einführst wo mehrere Threads lesen und schreiben, führst du eine neue CritSect ein. So können die Threads auch dann noch die zweite Sache abarbeiten, während es bei der ersten vielleicht nicht geklappt hat.

Zitat von Michael_Bayer:

Allerdings kommt mir das etwas.. naja.. ineffektiv vor.
Ich muss ja dann auch bei Leseoperationen auf ein Objekt, dass woanders geschrieben werden könnte, eine CriticalSection benutzen - so werden ja auch Leseoperationen serialisiert...muss das sein?

Anders geht es nicht. Denn genau das ist ja das Problem, wenn sich mehrere Codeteile eine Ressource teilen. Der Punkt ist ja gerade, daß du die Geschichte so effektiv wie möglich gestalten sollst und kannst, indem du die rechenintensiven Sachen sinnvoll trennst und parallelisierst. Das ist aber ein eigenes Themengebiet der Informatik und kann sicherlich nicht in Gänze in einem solchen Thread hier abgehandelt werden