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.