Thread und Methodenaufrufe

[Mr_G]

Hallo zusammen.
Ich bastel wieder mal mit Threads (nonVCL bzw. nonRTL) rum, habe einen Thread innerhalb eines Objekts gestartet und zwar nach diesem Konzept: http://www.delphipraxis.net/internal...=758329#758329
Ich habe nun also ein Objekt welches einen Thread gestartet hat. Aus diesem Thread führe ich nun Methoden des Objekts aus bzw. greife lesend auf Propertys zu. Kann ich nun auch weiter problemlos aus dem "Hauptthread" auf die Propertys und Methoden zugreifen (bisweilen nur lesend), oder muss ich das sychronisieren?
Falls dies einer Synchronisation Bedarf: Wie mach ich das am elegantesten?

[sirius]

synchronisieren ist notwendig

Du machst es über getter und setter-Methoden, wobei das Lesen und schreiben z.B. über eine Critical Section abgesichert ist.
Alternativ kannst du dein Objekt von TMultiReadExclusiveWriteSynchronizer (oder so ähnlich) ableiten und mit den Beginxxx und endxxx Methoden arbeiten.

[Mr_G]

Wie sieht das denn bei Methodenaufrufen aus? Müssen die auch mittels Critical Section abgesichert werden? Kann man die überhaupt so nutzen?

[sirius]

Besser ist, du vermeidest das gleich vom Konzept her.
Du darfst halt nicht auf gleiche Speicherplätze, sprich gleiche Variablen, zugreifen.

[Mr_G]

Das Problem ist glaube ich das Konzept:
Es geht um eine Netzwerkanwendung (es sollen nur kleine Steuerbefehle gesendet werden) bei der ich den Empfang in einen Thread ausgelagert hab. Die Frage ist nun wie bewältige ich das Senden und Empfangen was den Datenaustausch mit dem Hauptthread betrifft.
Hauptproblem ist die Verwaltung der Clients: Ich brauche eine Datenstruktur in der die Clients gelistet sind, sodass ich Infos zu den Clients dort ablegen kann.
Der Haupthread soll dann "Anweisungen" geben können (z.B. Senden gewisser Daten), wobei der andere Thread sich dann um das Senden sowie die Verarbeitung der Empfangenen Daten kümmert.

[Apollonius]

Wenn nur ein Thread schreibt, brauchst du keine Synchronisation.

[SirThornberry]

Zitat:

Zitat von Apollonius

Wenn nur ein Thread schreibt, brauchst du keine Synchronisation.

Je nach dem wie groß die Daten sind schon. Und zwar damit der lesende Thread keine inkonsistenten Daten bekommt. Bei einem Array wäre es zum Beispiel unschön wenn Thread1 1 Arrayelement liest, dann Thread2 das zweite Arrayelement schreibt und Thread1 dieses dann liest. Denn dann würde eventuell der Inhalt des ersten Arrayelementes nicht mehr zum zweiten passen.

[Apollonius]

Stimmt. Bei einer einfachen Liste ist es allerdings ziemlich leicht, schreibende Zugriffe atomar sichtbar zu machen.

[alzaimar]

Schau Dir doch mal eine Threadpool-Klasse an, die ist genau dafür gedacht. Du definierst nur noch die Jobs, die im Hintergrund abzuarbeiten sind. Den Rest erledigt die Klasse.

Ich würde prinzipiell sowohl Getter und Setter mit Critical Sections schützen, auch die Operation an sich scheinbar unteilbar ist. Wer weiss, was zukünftige CPU's so bringen? Wer sagt mir denn, das die nächste CPU-Generation nicht in der Lage ist, einen 32bit-Wert parallel zu beschreiben bzw. zu lesen? Diese Schutzblöcke zeigen zudem direkt an, das das Objekt auch für den multithreaded-Betrieb ausgelegt ist (Stichwort: Selbsterklärender Code).

[Apollonius]

Intel wird wohl kaum CPUs auf den Markt bringen, die den gleichen Maschinencode wie heutige verstehen, aber auf subtile Weise inkompatibel sind. 32-Bit-Movs sind in den Handbüchern als atomar beschrieben. Jeder C-Compiler, der Volatile versteht, wird für 32-Bit-Schreibvorgänge auch nur movs generieren.

[himitsu]

Delphi-Quellcode:

lock mov [eax], edx

nur das der Delphicompiler mit dem lock manchma Probleme hat -.-°

[Apollonius]

Himitsu, wenn der Delphi-Compiler das zulassen würde, hätte das lediglich zur Folge, dass dir eine Invalid-Opcode-Exception um die Ohren fliegt. Das lock-Präfix ist nur für Anweisungen gültig, bei denen gelesen und geschrieben wird.

[himitsu]

ich kenn da manchma nur die "External Exception C000001E" in Verbindung mit MOV,
ansonsten geht's bei mov, or, xor, and, cmpxchg und co
und damit wird ja wohl geschrieben/gelesen (oftmals)

[Mr_G]

Danke für die zahlreichen Antworten!
Die Threadpool-Klasse kenne ich natürlich bereits, aber ich denke, dass es kompliziert wird mein Problem auf die Klasse zu übertragen (evtl. auch ein bisschen Overkill).
Das Konzept der Queue für die Jobs könnte ich aber vielleicht für mein Problem nutzen. Mir schwebt da schon etwas vor. Außerdem sollte eine Queue mittels Critical Sections doch ruck zuck Threadsicher zu machen sein, oder?

[sirius]

@himi und Apollo

Zitat:

Zitat von Intel(c)-64 und IA-32 Architcecture

The LOCK prefix can be prepended only to the following instructions and only to those
forms of the instructions where the destination operand is a memory operand: ADD,
ADC, AND, BTC, BTR, BTS, CMPXCHG, CMPXCH8B, DEC, INC, NEG, NOT, OR, SBB,
SUB, XOR, XADD, and XCHG. If the LOCK prefix is used with one of these instructions
and the source operand is a memory operand, an undefined opcode exception (#UD)
may be generated. An undefined opcode exception will also be generated if the LOCK
prefix is used with any instruction not in the above list. The XCHG instruction always
asserts the LOCK# signal regardless of the presence or absence of the LOCK prefix.

[Apollonius]

Das ist doch genau meine Rede. Alle diese Anweisungen lesen eine Speicherstelle aus und schreiben einen veränderten Wert zurück.