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?

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.

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

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

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.

Wenn nur ein Thread schreibt, brauchst du keine Synchronisation.

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.

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

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).

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.