Multithread Einstellungsobjekt refreshen

[shmia]

Wenn jeder Thread beim Erzeugen eine Kopie von MyConfig bekommt, dann wäre zumindest das Problem mit dem Mehrfachzugriff geregelt.
Noch besser wäre, wenn jeder Thread nur die Daten bekommt, die er auch braucht!

Wenn irgendjemand Geld vor dir möchte, dann gibst du ihm ja auch nicht deine Geldbörse mit
Bargeld, Kredit- und Visitenkarten, sondern du gibst ihm nur die Geldmenge die er haben will.
Aus dem gleichen Grund ist es unfein globale Objekte an Threads zu geben.

Fiktives Beispiel:

Delphi-Quellcode:

function CreateAndStartDatenleseThread: TDatenleseThread;
begin
  Result := TDatenleseThread.Create;
  Result.ComPort  := MyConfig.ComPort;
  Result.Baudrate := MyConfig.Baudrate;
  ...
  Result.Resume;
end

[QuickAndDirty]

Zitat von shmia:

Wenn jeder Thread beim Erzeugen eine Kopie von MyConfig bekommt, dann wäre zumindest das Problem mit dem Mehrfachzugriff geregelt.
Noch besser wäre, wenn jeder Thread nur die Daten bekommt, die er auch braucht!

Wenn irgendjemand Geld vor dir möchte, dann gibst du ihm ja auch nicht deine Geldbörse mit
Bargeld, Kredit- und Visitenkarten, sondern du gibst ihm nur die Geldmenge die er haben will.
Aus dem gleichen Grund ist es unfein globale Objekte an Threads zu geben.

Fiktives Beispiel:

Delphi-Quellcode:

function CreateAndStartDatenleseThread: TDatenleseThread;
begin
  Result := TDatenleseThread.Create;
  Result.ComPort  := MyConfig.ComPort;
  Result.Baudrate := MyConfig.Baudrate;
  ...
  Result.Resume;
end

Die Daten des Objektes werden nur gelesen. Wenn sie geändert werden dann müssen die Threads nach den neuen Daten arbeiten. Und geändert werden sie nur von genau einem Thread der eben ein Webinterface mit diesen Einstellungen bereitstellt. Ich kann also nicht viel mit threadlokalen Kopien dieser Daten anfangen.

Was passiert wenn ich BeginWrites im selben threat kaskadiere?

Delphi-Quellcode:

BeginWrite;
BeginWrite;
EndWrite;
EndWrite;

Oder BeginReads im WriteLock block des selben threads nutze?

Delphi-Quellcode:

BeginWrite;
BeginRead;
EndRead;
EndWrite;

geht das?

Eine Sache wäre da noch. Gibt es 'ne Möglichkeit threadsichere Getter und Setter für Published Properties automatisch zu erzeugen?
Oder gibt es ein "Synchronized", "Threadsafe" oder "Atomic" Flag oder so für Properties?

[himitsu]

In einem Thread ist es erstmal grundsätzlich egal, ob man BeginRead und BeginWrite verschachtelt.

Aber es könnte zu einem DeadLock führen, wenn mehrere Thread sowas machen.
Jedenfalls muß/sollte man bei einer Verschachtelung immer das "Höherwertige" zuerst sperren.
höherwertig/restriktiv = Write
niederwertig/extensiv = Read


keine Probleme

Delphi-Quellcode:

Thread 1:
BeginRead
...
EndRead

Thread 2:
BeginRead
...
BeginWrite
...
EndWrite
...
EndRead

Wenn aber zwei/mehrere Threads das machen, was Thread 2 macht,
dann würden alle Threads bei BeginWrite für immer auf die jeweils Anderen warten, welche gleichzeitig via BeginRead gesperrt haben, wärend sie auf BeginWrite warten, da BeginWrite darauf wartet, daß sich kein anderer Thread im Lese- und Schreibzugriff befindet.

Das Selbe geschieht auch, wenn man z.B. zwei/mehrere CriticalSections verschachtelt ... auch da muß man überall die CS in der selben Reihenfolge sperren und muß immer alle "höheren" mit sperren.
z.B. CS1, CS2 und CS3 müssen immer in dieser Reihenfolge gesperrt wernden und selbst wenn man nur CS2 braucht, dann muß dennoch vorher CS1 gesperrt werden, damit kein DeadLock entstehen kann.

[Sir Rufo]

Eine CriticalSection regelt nicht nur den Zugriff sondern hilft auch dabei konsistente Daten auszutauschen.
Dieses funktioniert bei MultiReadExclusiveWrite nicht, denn wenn der Comport schon geändert wurde, aber noch nicht die Baudrate, etc. dann habe ich inkonsistente Daten.

Mein Vorschlag:

Der Schreiber-Thread sperrt zum Schreiben das Config-Objekt über eine CS, trägt alle Daten ein und gibt die Sperre wieder frei.
Die Leser-Threads holen sich von dem Config-Objekt eine Kopie ab und lesen von dort die Einstellungen.
Der Leser-Thread entscheidet nun, zu welchem Zeitpunkt er die Daten haben will. Dazu bietet das Config-Objekt zwei Methoden an:

1. Config-Daten nur dann kopieren, wenn es nicht gesperrt ist (CS.TryEnter)
2. Config-Daten kopieren erzwingen, auch wenn man warten müsste (CS.Enter)

Der Thread kann sich nun entscheiden, ob er sich bremsen lassen will, oder es hinnehmen kann mit den "alten" Daten zu arbeiten (die vor ein paar Millisekunden noch "aktuell" waren)

[himitsu]

Zitat von Sir Rufo:

... sondern hilft auch dabei konsistente Daten auszutauschen.

Das simmt so nicht ganz.

Wenn etwas "gemeinsam" (zusammenhängend) gesetzt oder ausgelesen werden muß, dann muß man dieses auch gemainsam schützen/blockieren
und das trifft sowohl auf die CS, als auch auf den MREW zu.

[Sir Rufo]

Zitat von himitsu:

Zitat von Sir Rufo:

... sondern hilft auch dabei konsistente Daten auszutauschen.

Das simmt so nicht ganz.

Wenn etwas "gemeinsam" (zusammenhängend) gesetzt oder ausgelesen werden muß, dann muß man dieses auch gemainsam schützen/blockieren
und das trifft sowohl auf die CS, als auch auf den MREW zu.

Du hast Recht, das geht mit dem MREW genauso und der bietet sich in diesem Fall dafür sogar an.
Allerdings halte ich es für unerlässlich, dass jeder Thread eine Kopie der Daten hat, denn nur der Thread selber kann entscheiden, wann er bereit für eine neue Config ist und kann diese dann abholen. Wird dort gerade die Config überarbeitet, dann wartet er (und alle anderen) solange, bis dort gelesen werden kann.

[QuickAndDirty]

Zitat von Sir Rufo:

Zitat von himitsu:

Zitat von Sir Rufo:

... sondern hilft auch dabei konsistente Daten auszutauschen.

Das simmt so nicht ganz.

Wenn etwas "gemeinsam" (zusammenhängend) gesetzt oder ausgelesen werden muß, dann muß man dieses auch gemainsam schützen/blockieren
und das trifft sowohl auf die CS, als auch auf den MREW zu.

Du hast Recht, das geht mit dem MREW genauso und der bietet sich in diesem Fall dafür sogar an.
Allerdings halte ich es für unerlässlich, dass jeder Thread eine Kopie der Daten hat, denn nur der Thread selber kann entscheiden, wann er bereit für eine neue Config ist und kann diese dann abholen. Wird dort gerade die Config überarbeitet, dann wartet er (und alle anderen) solange, bis dort gelesen werden kann.

Ich überlege ob es möglich ist, dass das Objekt sich selbst dem jeweiligen thread in einer beständigen Kopie zur Verfügung stellt.
Die Kopie würde dann über ein Dirtyflag anzeigen können das sie veraltet ist und
eine Refresh Funktion könnte dann vom Thread aufgerufen die Kopie aktualisieren.

So hätte ich konsistente und Lesevorgänge und sichere Schreibvorgänge.