Synchronisierung von Subthreads (VCL) + Pointerzugriff

[markusj]

Hallo Leuts,

ich hab mal eine kleine Frage:

Ich habe einen VCL-Thread dem ich (als Beispiel) einen Zeiger auf einen Boolan-Wert übergeben habe.
So, nun einige Frage (insbesonderen an den Thread-Experten v.D. Luckie *g*):

Kann ich einfach auf diesen Boolean-Wert aus dem Thread zugreifen?
Wenn nein, wie kann ich das ganze Synchronisieren? Ich weis wie ich normale Prozeduren und Funktionen untereinander Synchronisiere, aber hier müsste ja eine Thread-Interne Prozedur Synchronisiert werden ... oder geht das genauso mit Synchronize???

EDIT: Und wenn wir schon dabei sind ... wie sieht das ganze mit einem TMemoryStream aus? Auf diesen wird allerdings !garantiert! nicht vom Hauptthread zugegriffen! (wird von mir gelockt)

Aber das wars noch nicht, ich habe noch einen weitere Frage ... Wie kann ich zwei Nebenthreads miteinander Synchronisieren, ohne über den Hauptthread zu gehen? Diese beiden Thread sollen nämlich miteinander kommunizieren.

mfG

Markus

[xaromz]

Hallo,

eine Möglichkeit wären CriticalSections. Such mal in der Hilfe nach EnterCriticalSection.

Gruß
xaromz

[markusj]

Für was? Den Variablenzugriff, den Threadzugriff oder beides ... ach ja, ich wusste gar nicht, dass das auch bei VCL geht^^.

mfG

Markus

[xaromz]

Hallo,

Zitat:

Zitat von markusj

Für was? Den Variablenzugriff, den Threadzugriff oder beides

Für alles natürlich. Ein Thread läuft von EnterCriticalSection durch bis LeaveCriticalSection, ohne dass ein anderer Thread dazwischenfunken kann.
// Anmerkung: Deshalb sollten diese Befehle auch sehr sparsam verwendet werden und der Code dazwischen kurz und effizient sein.

Zitat:

Zitat von markusj

ach ja, ich wusste gar nicht, dass das auch bei VCL geht^^.

Die Methode TThread.Synchronize benutzt nichts anderes als Enter-/LeaveCriticalSection. Was soll die VCL auch sonst verwenden wenn nicht das Windows-API?

Gruß
xaromz

[Basilikum]

Zitat:

Zitat von xaromz

Die Methode TThread.Synchronize benutzt nichts anderes als Enter-/LeaveCriticalSection. Was soll die VCL auch sonst verwenden wenn nicht das Windows-API?

das stimmt so nicht ganz: Synchronize platziert in der Message-Queue eine Nachricht, der Hauptthread möge doch bitte im Rahmen des Message-Processing die übergebene Callback-Funktion aufrufen... so wird sichergestellt, dass die Funktion synchron zum (dh. vom) Hauptthread ausgeführt wird

[markusj]

So, noch eine Frage: Wie sieht die sache aus, wenn ich 100% sicherstellen kann,dass kein Zugriff auf die Eigenschaft erfolgt?
Kann ich dann darauf verzichten?
Das Problem ist ganz einfach, dass ich einen TMemoryStream in eine Klasse im Hauptthread habe, die u.a. diesen Stream verwaltet.
Eine leistungsintensive Aufgabe habe ich in einem seperaten Thread ... und dieser soll auf den MemoryStream zugreifen.
Kann ich in dem Fall auf TCriticalSections verzichten? Die Klasse blockiert jeden Zugriff auf den Stream (von Auserhalb) während der Threadlaufzeit.

mfG

Markus

[xaromz]

Hallo,

Zitat:

Zitat von Basilikum

das stimmt so nicht ganz: Synchronize platziert in der Message-Queue eine Nachricht, der Hauptthread möge doch bitte im Rahmen des Message-Processing die übergebene Callback-Funktion aufrufen... so wird sichergestellt, dass die Funktion synchron zum (dh. vom) Hauptthread ausgeführt wird

Weiß ich doch :wink: ; ich wollte nur darauf hinweisen, dass die VCL für Synchronisation auch CriticalSections verwendet. Was Synchronize innerhalb der Section macht, ist ja nebensächlich.

Zitat:

Zitat von markusj

Das Problem ist ganz einfach, dass ich einen TMemoryStream in eine Klasse im Hauptthread habe, die u.a. diesen Stream verwaltet.
Eine leistungsintensive Aufgabe habe ich in einem seperaten Thread ... und dieser soll auf den MemoryStream zugreifen.
Kann ich in dem Fall auf TCriticalSections verzichten? DIe Klasse blockiert jeden zugriff auf den Stream während der Theradlaufzeit.

Wenn Du hundertprozentig sicher bist, dass kein gleichzeitiger Zugriff stattfindet, dann kannst Du auch darauf verzichten. Du solltest aber bedenken, dass dann eine Änderung am Programmdesign evtl. große Auswirkungen haben kann (man vergisst sowas nämlich auch schnell wieder). Du solltest unbedingt dokumentieren, wass Du da machst.
Besser ist es immer, sich abzusichern. Und Fehler zu debuggen, die auf solche Konstrukte zurückzuführen sind, wünsch' ich meinem ärgsten Feind nicht :zwinker: .

Gruß
xaromz

[markusj]

OK, das gehört zum Klassendesign, dass immer nur eine Aufgabe ausgeführt wird, solange wird ein Lock gesetzt, damit nicht verändert wird.

So noch eine wichtige Frage: Wie sieht das ganze bei einer Synchronisierung von zwei Subthreads untereinander aus? Muss das TCriticalSections dort auch als globale Variable vereinbart sein? Oder reicht es, wenn es in der Thread-Klasse des Kind-Threades als public vereinbart wird und somit dem Mama-Thread zu verfügung steht?

Eine kurze Struktur meiner Idee:

Hautpthread
||
Mama-Thread mit uses ClassKind-Thread
|
Kind-Thread mit TCriticalSections als Public

Funktioniert das?

mfG

Markus

[markusj]

So, noch eine Frage (nach der obigen, die noch nicht beantwortet ist):

Wie sieht die Sache umgekehrt aus? Wie greift der Hauptthread auf den Nebenthread zu?
Critical Sections? Hat der Hauptthread auch ein Synchronize, oder muss ich hier zu Fuß Synchronisieren?

mfG

Markus

[alzaimar]

Gemeinsam verwendete Resourcen/Variablen etc. sollten für den Zugriff grundsätzlich gekapselt werden, so etwa:

Delphi-Quellcode:

Procedure ThreadsafeSetValue (aMyValue : TSomeType);
Begin
  myCS.Enter;
  Try
    fValue := aMyValue; // Na ja, fValue.Assign bei Objekten
  Finally
    myCS.Leave;
  End
End;

Procedure ThreadsafeGetValue (Var aMyValue : TSomeType);
Begin
  myCS.Enter;
  Try
    aMyValue := fValue;
  Finally
    myCS.Leave;
  End
End;

Wenn Du das als Get/Set-Methoden einer Eigenschaft implementierst, ist der Zugriff darauf sicher. Zum Verständnis: Eine Critical Section hält nicht etwa alle anderen Threads an, sondern sorgt dafür, das ein zweiter Aufruf von myCS.Enter so lange wartet, bis der erste Aufrufer myCS.Leave aufgerufen hat. Der erste Aufruf von myCS.Enter schließt sozusagen eine Tür von *innen*. myCS.Leave öffnet sie wieder.