Was kostest es schon mal eben ein Objekt mit 20 String-,Int- und Double-Properties zu kopieren?
So gut wie nichts.
Wenn ich das Ganze 3x am Tag mache, dann ist das zu vernachlässigen. In zeitkritischen Anwendungen würde ich nicht so leichtfertig damit umgehen. Zumal ein Objekt bzw. dessen Daten auch mal größer werden können und dann ist so ein Ansatz einfach Quark. Bei kleinen Objekten fällt das aber nicht so sehr ins Gewicht, da hast Du sicherlich Recht. Aber wenn wir uns über 'best practises' unterhalten, dann ignorieren wir Sonderfälle wie 'kleine Datenmengen' mal lieber bzw. listen sie explizit auf.
Zitat:
Ein Thread, der nur auf eigenen Daten arbeitet ist sicher gegen konkurrierende Zugriffe & Deadlocks.
Nun ja, eine Critical Section schafft sichere und robuste Abhilfe.
Grundsätzlich: Wenn die Daten nur in eine Richtung gehen (was sie hier nicht tun, siehe Eingangspost), dann wäre es sicherlich am einfachsten, die Daten zu kopieren.
Aber hier scheinen Daten/Feedback aus dem Thread heraus verarbeitet werden zu müssen.... Hmm, ich mach das eigentlich automatisch immer so, das ich die Parameter des Threads im Konstruktor übergebe (so wie Du das machen würdest, also 'copy') und etwaiges Feedback über synchronisierende Eigenschaften (Critical Sections) oder Synchronize-Aufrufe (Events) der Außenwelt zur Verfügung stelle.
Ich denke, das ist dann wirklich die bessere (=robustere) Vorgehensweise.
