Datenaustausch zwischen Threads (Sync)

[fuchsle]

Hallo zusammen,

ich habe die Suchfunktion nun schon länger geplagt und schon einige Beispiele durch. Leider hat es mir noch immer nicht auf die Sprünge geholfen.

Bei ist ein Thread zuständig Daten zu sammel, der Andere soll Diese per TCP/IP bereitstellen.
Beide Threads arbeiten wie erwartet, aber sobald ich die gesammelten Daten (4 double) in die property des anderen thread schreiben möchte bekomm ich eine Fehlermeldung:

Zugriffsverletzung ... Schreiben von Adresse ...

Delphi-Quellcode:

      Synchronize(ExtUpdate);

// ...

procedure ThreadValue.ExtUpdate;
begin
  TCPIP.TCP_NO2_10 := NO2_10;
  TCPIP.TCP_NO2_06 := NO2_06;
  TCPIP.TCP_CompAir := CompAir;
  TCPIP.TCP_Coolant := Coolant;
end;

Bisher bin ich davon ausgegangen, dass ich mit einem Synchronize() es schaffe auf den anderen Thread zu zu greifen.


Ich bin über eure Hilfe dankbar,
leider noch Anfänger, was Delphi betrifft und OOP, daher evtl. auch auf dem Holzweg :(

[CCRDude]

Schau Dir mal TMultiReadExclusiveWriteSynchronizer an :)

[BUG]

Zitat:

Zitat von fuchsle (Beitrag 1126237)

Bisher bin ich davon ausgegangen, dass ich mit einem Synchronize() es schaffe auf den anderen Thread zu zu greifen.

Synchronize() bringt dich in den Kontext des Hauptthreads, dein anderer Thread ist davon nicht betroffen.

[Sir Rufo]

Es gibt von Synchronize aber auch noch ein paar überladene Methoden, wo man den gewünschten Thread-Kontext angeben kann.

Ansonsten mit Critical Sections arbeiten, wenn die Daten einfach nur abgeliefert werden sollen.

Und anstatt Synchronize kann man es auch mal mit Queue versuchen :)

[BUG]

Zitat:

Zitat von Sir Rufo (Beitrag 1126309)

Es gibt von Synchronize aber auch noch ein paar überladene Methoden, wo man den gewünschten Thread-Kontext angeben kann.

Leicht OT: wie soll das funktionieren?
Beim MainThread ist es ja leicht vorstellbar, da der quasi Ereignisgesteuert ist.
Aber in Execute kann ich doch machen was ich will, wie soll man da ein synchronisiertes Event hereinschmuggeln?

EDIT: Oder meinst du die statischen Methoden:

http://docwiki.embarcadero.com/VCL/en/Classes.TThread.Synchronize

The current thread is passed in the AThread parameter.

[Sir Rufo]

U are right :) das mit dem Sync kann man da vergessen.

Somit verbleibt als Lösung eine Queue zwischen die beiden Threads zu legen, die von dem einen befüllt und dem anderen abgearbeitet wird.
Das Befüllen und Auslesen muss zwingend mit einer CriticalSection abgesichert werden, oder alternativ mit dem MultiRead-Onkel ;)
Da es sich aber nur um einen Thread handelt wird das keine Vorteile ergeben, aber auch keine Nachteile.

[chaosben]

Zitat:

Zitat von CCRDude (Beitrag 1126248)

Schau Dir mal TMultiReadExclusiveWriteSynchronizer an :)

Als Alternative gibts dann nach die TCriticalSection aus der Unit SyncObjs

[mjustin]

Zitat:

Zitat von chaosben (Beitrag 1126360)

Zitat:

Zitat von CCRDude (Beitrag 1126248)

Schau Dir mal TMultiReadExclusiveWriteSynchronizer an :)

Als Alternative gibts dann nach die TCriticalSection aus der Unit SyncObjs

Und dann ist da noch System.TMonitor (für das eigens TObject erweitert wurde).

[Sir Rufo]

Zitat:

Zitat von chaosben (Beitrag 1126360)

Zitat:

Zitat von CCRDude (Beitrag 1126248)

Schau Dir mal TMultiReadExclusiveWriteSynchronizer an :)

Als Alternative gibts dann nach die TCriticalSection aus der Unit SyncObjs

Eine TCriticalSection sperrt aber immer komplett beim Lesen und Schreiben (Enter..Leave), der TMultiReadExclusiveWriteSynchronizer sperrt aber immer nur bei Schreibzugriffen (BeginWrite..EndWrite).
Somit sind die schon mal A sehr verwandt und B in einer MultiThread-Umgebung besser.

Allerdings in dieser vom TE aufgezeigten Konstellation nicht notwendig (2 Threads schreibend, 1 Thread lesend) ;)
Der Aufwand die beiden zu implementieren bleibt aber gleich, somit würde ich dem TMultiReadExclusiveWriteSynchronizer wohl doch den Vorzug geben :)

[himitsu]

Zitat:

Zitat von Sir Rufo (Beitrag 1126379)

Eine TCriticalSection sperrt aber immer komplett beim Lesen und Schreiben (Enter..Leave), der TMultiReadExclusiveWriteSynchronizer sperrt aber immer nur bei Schreibzugriffen (BeginWrite..EndWrite).
Somit sind die schon mal A sehr verwandt und B in einer MultiThread-Umgebung besser.

Wenn sich aber beim Lesen etwas verändert, dann zählt das als Schreibzugriff und muß ebenfalls gesperrt werden.
z.B. das Auslesen eines Streams, wo sich ja der Positionszeiger ändert.