Hallo,

Ich bin leider nicht 100%ig schlau geworden bisher. Kann mir jemand in wenigen Sätzen den Unterschied der im Titel genannten Objekte zur Synchronisation von Threads erklären?
Und für welche Anwendungsgebiete ist was am besten?

In meinem Fall geht es um ein TDictionary auf das aus mehreren Threads heraus zugegriffen werden kann. Momentan habe ich das über ein Mutex geregelt (was zu funktionieren scheint).
Aber was ist jetzt der Unterschied zu TMonitor und critical sections? Was ist in meinem Fall besser?

Abgesehen davon gibt es so viel was man bei Threads falsch machen kann. Gibt es da vllt. ein Guide o.ä. mit allem was man beachten muss?
Habe bisher nur ab und zu was mit Threads gemacht aber oft hatte ich (vllt auch unbegründet) ein schlechtes Gefühl dass mir gleich evtl. alles um die Ohren fliegt weil ich irgendwo irgendwas nicht ganz richtig gemacht hab und es dann vllt unter bestimmten Umständen knallen könnte.

Soweit ich weiß, sind das Synonyme. Konzeptionell kann ich zwischen den dreien jedenfalls keinen Unterschied erkennen. Mutex ist für mich die neutrale Bezeichnung, Windows nennt sie halt Critical Section, und Monitor kommt von Java.
Wozu man eine TMonitor-Klasse jetzt gerade in Delphi auch noch braucht, ist mir schleierhaft. Mein Gefühl ist schon lange, dass Embarcadero nicht genug qualifizierte Entwickler mit Delphi-Erfahrung findet und Quereinsteiger mit Java-Background einstellt. Deshalb findet man immer mehr Konzepte, die sich in Delphi wie ein Fremdkörper anfühlen. Laut diesem Blog ist TMonitor übrigens auch gleich mal um den Faktor 10 aufgeblähter und langsamer als die alten CriticalSections, wohl damit der Java-Entwickler sich auch gleich zuhause fühlt.

Ein paar Tipps zur Multithreadentwicklung: So kurze Code-Abschnitte wie möglich locken, und möglichst immer beim Aufrufer und nicht in der aufgerufenen Funktion. Als Programmierer hat man ja sonst immer die Tendenz, Komplexität durch Kapselung in Subroutinen zu verbergen. Bei kritischen Abschnitten ist das jedoch nach meiner Erfahrung kontraproduktiv. Es ist besser, wenn man direkt sieht, wo die kritischen Abschnitte verlaufen. Dadurch erkennt man eher, wo Deadlocks entstehen könnten.

Ich habe außerdem die Erfahrung gemacht, dass rekursive Mutexe zu schlechtem Code führen. Rekursiv heißt, dass man innerhalb eines Threads ein Mutex mehrfach locken und unlocken kann. (Beispiel: Mutex.Lock; Mutex.Lock; Mutex.Unlock; Mutex.Unlock; ) Bei nichtrekursiven Mutexen gäbe es dagegen beim 2. Lock-Versuch einen Deadlock (es spielt keine Rolle, dass man sich immer noch im gleichen Thread befindet). Das passiert zum Beispiel bei pthreads unter Linux und war für mich erst ungewohnt, weil ich es von Windows so kannte, dass alle Critial Sections standardmäßig rekursiv sind. Ich muss im Nachhinein aber sagen, dass ich weniger Probleme habe, seit ich mit nichtrekursiven Mutexen arbeite, weil man so gezwungen ist, besser über das Problem nachzudenken. Man kann alles, was man mit rekursiven Mutexen machen kann, auch ohne machen, und die Lösung ist am Ende sauberer.

Für Windows gilt: Critical Sections sind schneller als ein Mutex, aber dafür nicht global. Eine CS ist kein Kernelobjekt (hat ja auch kein Handle), erfordert deswegen keinen langsamen Kontextwechsel vom User Mode in den Kernel Mode. Jedenfalls wenn die CS nicht gesperrt ist. Eine CS kann nur für Threads innerhalb ein und desselben Prozesses benutzt werden. Ein Mutex dagegen ist ein Kernelobjekt, erfordert deshalb immer einen Kontextwechsel, kann dafür aber auch global über mehrere Prozesse hinweg benutzt werden.

Zu TMonitor kann ich nichts sagen.

TMonitor ist oft die schnellste Variante, da zuerst ein paar Spins versucht werden, ob es nicht vielleicht schon gleich funktioniert bevor die teure Variante (gemessen an Rechenzeit) mit WaitFor... Funktionen der API (WaitForSingleObject z.B., hab nicht geschaut was verwendet wird) benutzt wird.

Hat man TMonitor nicht eine katastrophale Performance nachgesagt bis sich dessen in XE5 angenommen wurde?

Auf jeden Fall hier ein bisschen Stoff: http://www.delphitools.info/2013/06/...iticalsection/

Das stimmt, das bezog sich auf die aktuellen Versionen. Aber man kann ja den SpinCount auch manuell jeweils setzen. Das ist eine der Änderungen, die das ganze schneller gemacht hat.

Den Spincount kann man übrigens auch bei Critical Sections einstellen / ändern.

"InitializeCriticalSectionAndSpinCount"

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

Mmt TMonitor war es die einzige Möglichkeit unter Android / Firemonkey, die ich gefunden habe, einen Thread äquivalent zu Windows mit Event + WaitforSingleObject aus dem Schlafmodus sofort aufzurufen.

.