Ja das ist klar. Sind im Prinzip alles triviale Typen, die ich syncen will (1, 2, 4 und 8 Byte). Habe mir über eine Helper Class bereits noch ein paar Funktionen für UInt32 und UInt64 hinzugefügt, da es die unsigned Varianten leider nicht standardmäßig gibt (dank des
var Parameters kann man auch nicht einfach casten).
Bin momentan am sichten, auf welche Felder in welcher Form von wo aus zugegriffen wird.
Momentan habe ich vier verschiedene Modi:
- Read im internen Thread UND externen Threads, Write nur im internen Thread
- Benötigte eine gesyncte Read Funktion, eine ungesyncte Read Funktion (für den internen Thread aus Performancegründen) und eine gesyncte Write Funktion
- Read im internen Thread UND externen Threads, Write im internen UND externen Threads
- Benötigte eine gesyncte Read Funktion und eine gesyncte Write Funktion
- Read im internen Thread UND externen Threads, Write einmal im Konstruktor bevor irgendein Zugriff von irgendwo möglich ist
- Muss nicht synchronisiert werden
- Read nur in externen Threads, Write einmal im Konstruktor bevor irgendein Zugriff von irgendwo möglich ist
- Muss nicht synchronisiert werden
Hoffe ich habe da grade keine Logikfehler eingebaut.
Und die Synchronisationsobjekte (unter System.SyncObjs) leiten sich doch alle von einer gemeinsamen Oberklasse ab. Wenn du später eine die TCriticalSection gegen etwas anderes austauschen willst, ist das nur eine Sache- Ich hätte Sir Rufos Ansatz noch um eine Typdefinition erweitert
Die Interlocked Funktionen sind allerdings nicht in der selben Form in einem SyncObject gekapselt. Austauschen werde ich die Synchronisierungsobjekte allerdings wohl eh niemals.