also .. das Problem bei Threads ist eigentlich nur, dass ein Thread Daten schreibt, noch gar nicht fertig ist, und ein anderer Thread diese Daten schon liest, und dann "halb" richtige Daten liest.
Stell Dir einen Integer vor, der hat 32 Bit. also 4 Bytes.
Ein Thread fängt jetzt an, diesen Integer von 4 Byte zu schreiben und ist gerade fertig geworden mit einem Byte.
(Auch wenn es nur ein Befehl in Delphi ist, sind es unter umständen mehrere Befehle in Assembler für den Prozessor)

Wenn jetzt gerade in dem Moment ein anderer die Daten liest, dann liest er 4 Byte.
Ein Byte ist schon aktuell, die anderen 3 Byte sind noch irgendwelcher Quatsch, der vorher drin war.
Jetzt liest er einen völlig anderen Integer, als gewollt.

Es soll Quelltext geben, die mit ungültigen Daten schlecht klar kommen und dann Exceptions verursachen


Deswegen darf das Schreiben von Daten immer nur hintereinander geschehen. Und von einem Thread !
Da es verschwendung wäre, Daten nur hintereinander zu lesen, dürfen also beim Lesen auch beliebig viele Threads auf Daten zugreifen.
Es muss nur sicher gestellt werden, dass gerade niemand schreibt in dieser Zeit.
Deswegen gibt es auch das lustige Object, dass früher mal Borland für Dich programmiert hat, mit dem lustigen Namen

"TMultiReadExclusiveWriteSynchronizer"

Eine kleine Ausnahme sind Datentypen, die nur ein Byte benötigen. das Macht der Prozessor in einem Rutsch, da kann auch niemand dazuwischenfunken ... das muss nicht syncrhonisiert werden... der Prozessor liest Byteweise, nicht Bitweise ..

Zitat:

Reicht es also, die CriticalSections im Zwischenobjekt bei der Übertragung auf den Thread2 anzubringen, oder müssen die vorher schon sein, da ja Daten von Thread1 in einem Objekt verändert werden, was Thread2 gehört? (veränderung erfolgt durch Aufruf der Methode des Zwischenobjektes)

kannst Du denn etwas Code posten?
wo liegen jetzt die Daten, auf die beide Threads gleichzeitig schreiben und lesen könnten?
Geschieht diese über "zentrale" Schreib und Lesefunktionen.
Wenn Du natürlich Globale Daten hast, auf die beide Threads zugreifen (auch den Hauptthread nicht vergessen, das ist auch einer)
dann musst Du auch ein globales Syncobject einführen ...


Wenn Du das lesen und schreiben allerdings an zentraler Stelle machst und alle Threads nur diese Funktionen aufrufen, dann nur dort .

Okay... Also das Zwischenobjekt ist in etwas so definiert:

zusammenfalten · markieren

Delphi-Quellcode:

TConnection = class
 private
  owner: TWThread;
  weight: Double;
 public
  constructor Create(aOwner: TWThread;aConn: TWThread);

  procedure ProcessSignal();
end;
procedure TConnection.ProcessSignal;
begin
 owner.ReceiveSignal;
 Inc(weight);
end;

Die Threads sehen in etwa so aus:

zusammenfalten · markieren

Delphi-Quellcode:

TWThread = class(TThread)
private
 value: Integer;
public
 constrctor Create;
 
 procedure CreateConnection(target: TWThread);
 function ReceiveConnRequest(link: TWThread): TConnection;

 procedure ReceiveSignal;
 procedure Execute();override;
end;

procedure TWThread.CreateConnection(target: TWThread);
begin
 connectionList.Add(target.ReceiveConnRequest(self));
end;

function TWThread.ReceiveConnRequest(link: TWThread): TConnection;
begin
 Result:=TConnection.create(self,link);
 ownedConns.Add(Result);
end;

procedure TWThread.Execute();
begin
 while not Terminated do
 begin
  if berechnungen_moeglich then
  begin
   rechnen;
   irgendwann do
    connectionList[item].ProcessSignal;
  end else Suspend;
end;

procedure TWThread.ReceiveSignal;
begin
 Inc(value);
 if Suspended then Resume;
end;

Zitat von stoxx:

wo liegen jetzt die Daten, auf die beide Threads gleichzeitig schreiben und lesen könnten?
Geschieht diese über "zentrale" Schreib und Lesefunktionen.

Die Daten liegen im Verbindungsobjekt, welches selbst einem Thread gehört. Dieses Objekt verschickt auch Daten an den Thread, dem es gehört. Lesender Zugriff wird unter den Threads nicht gemacht, aber von anderen Objekten der GUI.

Ist vielleicht jetzt etwas klarer...

Zitat:

Ist vielleicht jetzt etwas klarer...

eher nicht, weil nicht so recht ersichtlich ist,wo jetzt die gemeinsam genutzten Daten liegen.
und wann wie wo wer was nutzt.

es gibt auch eine Threadsichere TList, namens "TThreadList ", wenn es sich bei den "gemeinsam genutzten Daten um eine TList handelt. da kann man sich critical Sektions sparen und die Liste "locken" und "unlocken"
hab ich aber noch nie verwendet ..

hab meine erklärung nochmal bissl verändert. Eigentlich müsste das weitere Vorgehen damit jetzt klar sein, nur Du kennst Dein Anwendung ...

Zitat:

Lesender Zugriff wird unter den Threads nicht gemacht, aber von anderen Objekten der GUI.

die GUI ist der Hauptthread, und damit auch ein Thread ....
somit ergibt sich ein neues Problem .. die VCL ist nicht threadsicher ..

das heißt .. Kommunikation mit der GUI nur über die nicht ganz optimale Synchronize Funktion .....
da bleibt Dir leider nix anderes übrig ..

Zitat von stoxx:

Zitat:

Ist vielleicht jetzt etwas klarer...

eher nicht, weil nicht so recht ersichtlich ist,wo jetzt die gemeinsam genutzten Daten liegen.
und wann wie wo wer was nutzt.

Es wird nichts gemeinsam genutzt. Es wird nur ein Signal von einem zum anderen Thread gesendet, einen Zahlenwert um X einheiten zu erhöhen.
Wann wo wie welcher Thread daten nutzt ist aber wirklich unmöglich vorherzusagen. Es hängt von einem Threadinternen wert ab, der in Execute() bearbeitet wird, ob Thread1 ein Signal über das Linkobjekt an Thread2 sendet.

Wie benutze ich das TMultiReadExclusiveWriteSynchronizer? (wer hat sich den diesen sperrigen Namen ausgedacht?)

isch mach Dir mal ein Beispiel.

Zitat:

Wann wo wie welcher Thread daten nutzt ist aber wirklich unmöglich vorherzusagen.

oh doch, das solltest bei Threads Du sehr genau wissen .... sons wird das mit Threads nix ...

aber warte mal 5 Minuten ...

Wie benutze ich das TMultiReadExclusiveWriteSynchronizer? (wer hat sich den diesen sperrigen Namen ausgedacht?) Der TMultiReadExclusiveWriteSynchronizer macht nur bei großen Datenmengen Sinn, bei einzelnen Integern ist der etwas Oversized ...

Die Klasse erlaubt das gleichzeitige Lesen von Daten von mehreren Threads, sofern gerade kein Thread schreibt, stellt aber sicher, dass wenn geschrieben wird, alle anderen schreibenden und lesenden Threads blockiert werden ...

Wow! Ich habe jetzt mal die entsprechenden Stellen mit CriticalSections geschützt und - voilà, seit 2 Minuten keine Fehler mehr!
Hoffentlich bleibt das so... Aber schonmal vielen Dank! Sieht bis jetzt super aus!

EDIT: Zu früh gefreut... Ich bekomme wieder SIGFPEs ohne Backtrace... Der Fehler kann aber überall anders auch liegen. Ich schaue mir das nochmal genauer an.

Zitat:

Wann wo wie welcher Thread daten nutzt ist aber wirklich unmöglich vorherzusagen. Es hängt von einem Threadinternen wert ab, der in Execute() bearbeitet wird, ob Thread1 ein Signal über das Linkobjekt an Thread2 sendet.

seine eigenen Daten darf natürlich jeder Thread nutzen wie er will ...
zu beachten ist allerdings, dass nur die Execute Methode im Thread läuft.
alle anderen Funktionen laufen im Hauptthread .. es sei denn , sie werden von Execute Aufgerufen.
Datenzugriffe in einer THread Klasse können also dennoch von unterschiedlichen Threads aufgerufen werden ...
Was zu beachten wäre ...

Zitat:

EDIT: Wow! Ich habe jetzt mal die entsprechenden Stellen mit CriticalSections geschützt und - voilà, schon seit 4 Minuten keine Fehler mehr! Hoffentlich bleibt das so... Aber schonmal vielen Dank! Sieht bis jetzt super aus! ?)

na das ist doch schön

So, jetzt läuft wirlich alles! Die verbelibenden Fehler hatte alle mit der grafikbibliothek Qt4 zu tun und sind jetzt behoben. Ein "CriticalSection" in den Zeichenfunktionen hat sich dabei als sehr sinnvoll herausgestellt, obwohl da nur gelesen wird. (Aber wenn man versucht, was zu lesen was nicht existiert ist das halt ein Problem...)
Nochmals vielen Dank!