Wenn die GUI schreibend und der Thread lesend gleichzeitig zugreifen, kann es eng werden, dies tritt aber nur bei echter Parallelverarbeitung auf (MultiCore).

Imo ist das immer unkalkulierbar.
Wenn das Gui eine Änderung an den Settings vornimmt, hast du keine Ahnung, ab welchem Zeitpunkt diese Änderung auch im Nebenthread wirksam ist.
Du mußt also davon ausgehen, dass der Nebenthread lustig mit den falschen Setting-Werten erstmal weiter-arbeitet.

Hi
SyncLock sorgt dafür, dass der Code-Abschnitt im SyncLock selber nur auf einem Thread ausgeführt wird. Wenn du den Zugriff auf Objekte synchronisieren möchtest, kannst du System::Threading::Monitor verwenden. Es gibt auch noch andere Synchronisationsmechanismen, aber dieser scheint hier je nach Veerwendung angebracht.
Beim Threading wird jedem Thread eine bestimmte Zeit zum Arbeiten gegeben. D.h. Verhalten sichern, wo es sinnvoll ist.

Gruß
~blaze~

~blaze~ schrieb:

SyncLock sorgt dafür, dass der Code-Abschnitt im SyncLock selber nur auf einem Thread ausgeführt wird.

ziemlich ungenau.

Synclock macht aus einem beliebigen Objekt eine Thread-Sperre.
Solange ein Lock auf dem Objekt ist, können andere Threads keinen Synclock-Bereich betreten, der dasselbe Objekt lockt.

Also wenn du ein Objekt lockst und dann einen Schreibvorgang auf eine Liste ausführst, dann kannst du an anderer Stelle was zum Lesen aus der Liste coden, und das in einen Synclock-Block tun, der dasselbe Objekt lockt.
Ergebnis: wenn geschrieben wird warten lesende Threads solange, und anschließend sind die aktuellen Daten verfügbar.

@blaze: was macht Monitor im Gegensatz zu Synclock?

Nichts anderes, da SyncLock ebenfalls auf Monitor basiert. Er ist allerdings "allgemeiner", als SyncLock, da End SyncLock mit SyncLock in einem Block stehen muss.

Gruß
~blaze~

Mono schrieb:

Kann es irgendwie zu Problemen kommen

Ja. Das hängt aber vom Typ der Property ab bzw vom Code der in der Property-Methode steht.

Bsp.:
If Dic.ContainsKey("foo") then Return Dic("foo")

sieht trivial aus, aber was, wenn genau VOR dem Return, aber nach dem .Contains genau dieses Element aus dem Dictionary gelöscht wird? Beides sind rein lesende Vorgänge, aber nichts stellt sicher, dass zwischen den beiden Vorgängen kein anderer Thread läuft, der schreibend/löschend ist.

Zu Exceptions nicht, aber zu falschen Ergebnissen (es sei denn der Wert wird nur am Anfang einmal geschrieben und dann wirklich nur noch gelesen).

Der Monitor bzw. SyncLock gehört in die Settings-Klasse und bekommt ein privates Lock-Objekt, damit jeder, der auf irgendwelche Eigenschaften zugreift, vom gleichen Lock blockiert wird.

Falsch:


Richtig:


Mit mehreren Locks kannst du die Properties voneinander unabhängig machen. Wenn ein Wert niemals von verschiedenen Thread gebraucht wird, kann er ein eigenes Lock bekommen, sodass andere Threads (in anderen Properties) nicht blockiert werden. Wird aber schnell kompliziert. Vielleicht auch noch interessant für dich: Such mal nach der Klasse "ReaderWriterLock".

Mono schrieb:

Wie könnte man hier ohne Try Catch arbeiten?

a) Wozu
->
Das Acquire KÖNNTE schiefgehen. Was soll dann passieren? Anwendungsabsturz? Heulen und Zähnklappern beim Anwender? Oder ne MessageBox die den User auffordert es noch mal zu probieren oder alternativ seine Daten zu speichern und das Programm neu zu starten?

b) Wieso zwei Try-Catch?
->
try
rwl.AcquireReaderLock(timeOut)
...
finally
if rwl.isreaderlockheld then rwl.releasereaderlock

Mono schrieb:

Ich erinner mich nur an Diskussion deren eine Seite eine Argumentation hatte,

Diese Argumentation gibt es und in Bezug darauf zitiere ich mal aus "Zeit des Erwachens": Wenn Sie recht hätten, würde ich Ihnen zustimmen

Wie man sieht ist die hier geworfene Exception eine "Nachricht". Nachrichten hat man zu verarbeiten!
In C/C++ sähe die Signatur vermutlich SO aus:
public int AcquireReaderLock(int timeout)
Wenn alles OK, gibt die Funktion 0 zurück, ansonsten einen Int, der den Fehler näher beschreibt.
Typischer Aufruf in C/C++:
if (int err = AcquireReaderLock(int timeout))
{
// locking failed, wtf? Lets inform user and then go on
}

Eventuelle Syntaxfehler mögen der Tatsache geschuldet sein, dass ich halt KEIN native-born-c'ler bin

guck - ReaderWriteLock kannte ich noch garnet - scheint mir eine prima Lösung der SyncLock/Monitor - Unschönheit, dass gleichzeitige Lesevorgänge sich eigentlich unnötigerweise gegenseitig behindern, während doch nur sichergestellt sein muß, dass ein Schreibvorgang alle anneren Lese- und Schreib-Vorgänge warten lassen muß.

TryCatch kann man nicht immer vermeiden - imo sollmans vermeiden, wenn mans vermeiden kann, aber das geht halt nicht immer. gugge vlt. TryCatch ist ein heißes Eisen

Dieses ReaderLockWriter-Dings scheint numal so designed, dasses die TimeOut-Meldung via Exception mitteilt, und das ist ja auch ganz sinnvoll.
Olle SyncLock/Monitor sieht ja gar keinen TimeOut vor, sodasses in komplizierteren Fällen auch zu Situationen kommen kann, wo zwei Threads gegenseitig aufeinander warten, und die Anwendung steht still: Diese Form von Absturz heißt "DeadLock".

Mittm ReaderWriterLock fliegt dann iwann (nämlich genau nachm TimeOut) eine Exception, und dassis natürlich ein enormer Vorzug gegenüber einem DeadLock, bei dem ja garnix mehr geht.
Und hier im Demo besteht die ExceptionBehandlung halt in der Ausgabe der Exception - die wollen das Feature ja demonstrieren.

@Mono: Dein Sample findichjetz bisserl überkandidelt. Du willst doch nur einen neuen LogPath setzen.
Das würdeja nur zu einem Timeout führen können (keinesfalls zu einem Deadlock), wenn da bereits sekundenenlang herumgeloggt würde in deim LogPath, und zwar ein einziger Log-Vorgang - ist das realistisch?
Und da hättest du dann ein ganz besonderes Problem mitte Fehlerbehandlung: Wie logge ich einen Fehler, wenn ich den Pfad zur Log-Datei nicht setzen kann?
Das annere Problem ist, wenn wirklich sekundenlange Logs geschrieben werden - dann dürfte die Datei ziemlich bald Gigabyte groß werden.

Tatsächlich denke ich aber, der Logpfad wird zum StartUp ein einziges Mal gesetzt, und dann vlt. nochmal, wenn einer die Optionen entsprechend ändert. Und ein Log-Aufruf schreibt vlt. 200 Bytes.

lange rede kurzer sinn: Beim Loggen denke ich, dass ReaderWriterLock nicht das geeignete Mittel ist, denn es ist ein Mittel für viele Lese-Vorgänge und gelegentliche Schreiber.
Logging ist aber eiglich nur schreiben, und da ist SyncLock imo ganz i.O..

ErfinderDesRades schrieb:

Dieses ReaderLockWriter-Dings scheint numal so designed, dasses die TimeOut-Meldung via Exception mitteilt,

Kleiner Tip: DAS ist genau das Verhalten für das MS die Exception VORGESEHEN hat. MS hat sich nämlich VORSÄTZLICH gegen das (von mir oben aufgezeigte) "Fehlerschema" aus C/C++ entschieden.
Googles Go macht hat es da einfacher, denn da können Funktionen ihren "Wert" UND gleichzeitig (!) einen Fehler zurückmelden.

sehe immer noch keine Verwendung für einen TimeOut.

auch könnteman die Methode so gestalten, dass die Werte als Argument mitgegeben werden.
Zumindest beim LogLevel fände ich eigentümlich, wenn der nicht zusammen mit dem MeldeText geliefert würde, sondern wenn da immer vor einem Log-Aufruf noch ein Level extra zu setzen wäre.

Mono schrieb:

Du meinst also, das TimeOut generell weglassen bzw auf infinite setzen?

nein, ich meinte: Synclock benutzen.