- Ich denke der TMultiReadExclusiveWriteSynchronizer
ist eine angemessene Lösung wenn man wirklich die Aufgabenstellung hat wenn ein Wert über mehrere Threads abgesichert werden muss und hierbei sehr oft gelesen, aber nur selten geschrieben wird. Klar war dein Beispiel konstruiert, aber das Sleep(50)
ließ jetzt auf eine eher häufige Änderung schließen. Ein 100%iges Versprechen Deadlocks zu vermeiden kann dir auch ein TMultiReadExclusiveWriteSynchronizer
nicht geben, er bringt nur in speziellen Anwendungsfällen wohl bessere Performance.
- Ja, aber ob der exorbitant höhere Schreibaufwand und erhöhte Komplexität es wert ist dass das ursprüngliche Problem nur etwas verringert wurde?
Zu Punkt 3 & 4: Da hast du Recht. Ich hatte nur das Lesen auf dem Schirm, aber hochtheoretisch kann jemand setProp1(..) aufrufen, und vor der letzten Zeile wird der Thread angehalten und von einem anderen wird setProp2(..) aufgerufen. Der läuft komplett durch und später wird setProp1(..) noch ordentlich zu Ende gebracht. Keine Datenkorruption, aber das OnChange-Event wurde dann einfach zwei mal mit den neuen Werten aufgerufen.
Seit der PPL denken plötzlich alle, Multithreading und parallel programming sei nen Kindergeburtstag
Aus den Slides meines Vortrags auf den Delphi-Tagen 2013:
Zitat von
Danny Thorpe:
New programmers are drawn to multithreading like moths to flame, with similar results.