Die Theorie
Wenn ein Thread versucht, einen Mutex zu sperren, und dies nicht erfolgreich ist, weil der Mutex bereits gesperrt ist, wird er theoretisch in den Ruhezustand versetzt, sodass sofort ein anderer Thread ausgeführt werden kann. Es wird weiter schlafen, bis es aufgeweckt wird. Dies ist der Fall, sobald der Mutex von einem Thread entsperrt wird, der zuvor die Sperre gehalten hat. Wenn ein Thread versucht, einen Spinlock zu sperren, und dies nicht erfolgreich ist, versucht er kontinuierlich, ihn zu sperren, bis er schließlich erfolgreich ist. Daher kann kein anderer Thread seinen Platz einnehmen (das Betriebssystem wechselt jedoch zwangsweise zu einem anderen Thread, sobald das CPU-Laufzeitquantum des aktuellen Threads natürlich überschritten wurde).
Das Problem
Das Problem bei Mutexen ist, dass das Einschalten und erneutes Aufwecken von Threads ziemlich teure Vorgänge sind. Sie benötigen eine Menge CPU-Anweisungen und benötigen daher auch einige Zeit. Wenn der Mutex jetzt nur für eine sehr kurze Zeit gesperrt war, kann die Zeit, die zum Einschalten und erneuten Aufwecken eines Threads aufgewendet wird, die Zeit, in der der Thread tatsächlich geschlafen hat, bei weitem überschreiten und sogar die Zeit überschreiten, die der Thread benötigt haben durch ständige Abfrage auf einem Spinlock verschwendet. Auf der anderen Seite verschwendet das Abrufen eines Spinlocks ständig CPU-Zeit. Wenn die Sperre länger gehalten wird, verschwendet dies viel mehr CPU-Zeit und es wäre viel besser gewesen, wenn der Thread stattdessen geschlafen hätte.
Die Lösung
Die Verwendung von Spinlocks auf einem Single-Core- / Single-CPU-System ist normalerweise nicht sinnvoll, da kein anderer Thread ausgeführt werden kann, solange die Spinlock-Abfrage den einzigen verfügbaren CPU-Core blockiert, und die Sperre nicht ausgeführt wird, da kein anderer Thread ausgeführt werden kann entweder entsperrt werden. IOW, ein Spinlock verschwendet auf diesen Systemen nur CPU-Zeit ohne wirklichen Nutzen. Wenn der Thread stattdessen in den Ruhezustand versetzt wurde, könnte ein anderer Thread sofort ausgeführt worden sein, wodurch möglicherweise die Sperre aufgehoben und der erste Thread die Verarbeitung fortsetzen konnte, sobald er wieder aufwachte.
Auf einem Multi-Core- / Multi-CPU-System mit vielen Sperren, die nur für eine sehr kurze Zeit gehalten werden, kann die Zeit, die verschwendet wird, um Threads ständig in den Ruhezustand zu versetzen und sie wieder aufzuwecken, die Laufzeitleistung merklich verringern. Wenn Threads stattdessen Spinlocks verwenden, können Threads ihr volles Laufzeitquantum nutzen (immer nur für einen sehr kurzen Zeitraum blockieren, dann aber sofort ihre Arbeit fortsetzen), was zu einem viel höheren Verarbeitungsdurchsatz führt.
Die Übung
Da Programmierer sehr oft nicht im Voraus wissen können, ob Mutexe oder Spinlocks besser sind (z. B. weil die Anzahl der CPU-Kerne der Zielarchitektur unbekannt ist), können Betriebssysteme auch nicht wissen, ob ein bestimmter Code für Single-Core oder optimiert wurde In Multi-Core-Umgebungen unterscheiden die meisten Systeme nicht streng zwischen Mutexen und Spinlocks. Tatsächlich verfügen die meisten modernen Betriebssysteme über Hybrid-Mutexe und Hybrid-Spinlocks. Was bedeutet das eigentlich?
Ein Hybrid-Mutex verhält sich auf einem Mehrkernsystem zunächst wie ein Spinlock. Wenn ein Thread den Mutex nicht sperren kann, wird er nicht sofort in den Ruhezustand versetzt, da der Mutex möglicherweise bald entsperrt wird. Stattdessen verhält sich der Mutex zunächst genau wie ein Spinlock. Nur wenn die Sperre nach einer bestimmten Zeit (oder Wiederholungsversuchen oder einem anderen Messfaktor) immer noch nicht erreicht wurde, wird der Thread wirklich in den Ruhezustand versetzt. Wenn derselbe Code auf einem System mit nur einem Kern ausgeführt wird, wird der Mutex nicht spinlockiert, obwohl dies, wie oben gezeigt, nicht vorteilhaft wäre.
Ein Hybrid-Spinlock verhält sich zunächst wie ein normaler Spinlock. Um jedoch zu vermeiden, dass zu viel CPU-Zeit verschwendet wird, kann eine Back-Off-Strategie angewendet werden. Normalerweise wird der Thread nicht in den Ruhezustand versetzt (da dies bei Verwendung eines Spinlocks nicht geschehen soll), es kann jedoch sein, dass der Thread gestoppt wird (entweder sofort oder nach einer bestimmten Zeit) und ein anderer Thread ausgeführt werden kann Dies erhöht die Wahrscheinlichkeit, dass der Spinlock entsperrt wird (ein reiner Thread-Schalter ist normalerweise günstiger als einer, bei dem ein Thread in den Ruhezustand versetzt und später wieder aufgeweckt wird, wenn auch nicht bei weitem).
Zusammenfassung
Wenn Sie Zweifel haben, verwenden Sie Mutexe. Diese sind normalerweise die bessere Wahl, und die meisten modernen Systeme ermöglichen es ihnen, für sehr kurze Zeit einen Spinlock durchzuführen, wenn dies vorteilhaft erscheint. Die Verwendung von Spinlocks kann manchmal die Leistung verbessern, aber nur unter bestimmten Bedingungen und die Tatsache, dass Sie Zweifel haben, sagt mir eher, dass Sie derzeit an keinem Projekt arbeiten, bei dem ein Spinlock von Vorteil sein könnte. Sie könnten in Betracht ziehen, Ihr eigenes "Sperrobjekt" zu verwenden, das entweder intern einen Spinlock oder einen Mutex verwenden kann (z. B. könnte dieses Verhalten beim Erstellen eines solchen Objekts konfigurierbar sein), zunächst überall Mutexe zu verwenden und wenn Sie der Meinung sind, dass die Verwendung eines Spinlocks irgendwo wirklich möglich ist Hilfe, probieren Sie es aus und vergleichen Sie die Ergebnisse (z. B. mit einem Profiler), aber testen Sie beide Fälle.
Update: Eine Warnung für iOS
Eigentlich nicht iOS-spezifisch, aber iOS ist die Plattform, auf der die meisten Entwickler möglicherweise mit diesem Problem konfrontiert sind: Wenn Ihr System über einen Thread-Scheduler verfügt, garantiert dies nicht, dass ein Thread, egal wie niedrig seine Priorität sein mag, irgendwann eine Chance zum Ausführen erhält. dann können Spinlocks zu dauerhaften Deadlocks führen. Der iOS-Scheduler unterscheidet verschiedene Klassen von Threads, und Threads in einer niedrigeren Klasse werden nur ausgeführt, wenn kein Thread in einer höheren Klasse ebenfalls ausgeführt werden soll. Hierfür gibt es keine Back-Off-Strategie. Wenn also permanent hochklassige Threads verfügbar sind, erhalten niedrigklassige Threads niemals CPU-Zeit und somit keine Chance, Arbeiten auszuführen.
Das Problem sieht wie folgt aus: Ihr Code erhält einen Spinlock in einem Thread mit niedriger Prio-Klasse, und während er sich in der Mitte dieser Sperre befindet, hat das Zeitquantum überschritten und der Thread wird nicht mehr ausgeführt. Die einzige Möglichkeit, wie dieser Spinlock wieder freigegeben werden kann, besteht darin, dass dieser Thread mit niedriger Prio-Klasse wieder CPU-Zeit erhält, dies jedoch nicht garantiert ist. Möglicherweise haben Sie einige Threads der High-Prio-Klasse, die ständig ausgeführt werden sollen, und der Taskplaner priorisiert diese immer. Einer von ihnen kann über das Spinlock laufen und versuchen, es zu erhalten, was natürlich nicht möglich ist, und das System wird es nachgeben lassen. Das Problem ist: Ein Thread, der nachgab, kann sofort wieder ausgeführt werden! Mit einem höheren Prio als der Thread, der die Sperre hält, hat der Thread, der die Sperre hält, keine Chance, die CPU-Laufzeit zu erhalten.
Warum tritt dieses Problem bei Mutexen nicht auf? Wenn der High-Prio-Thread den Mutex nicht erhalten kann, gibt er nicht nach, dreht sich möglicherweise ein wenig, wird aber schließlich in den Ruhezustand versetzt. Ein schlafender Thread kann erst ausgeführt werden, wenn er von einem Ereignis geweckt wurde, z. B. einem Ereignis wie dem entsperrten Mutex, auf das er gewartet hat. Apple ist sich dieses Problems bewusst und ist daher veraltet OSSpinLock. Das neue Schloss wird aufgerufen os_unfair_lock. Diese Sperre vermeidet die oben erwähnte Situation, da sie die verschiedenen Thread-Prioritätsklassen kennt. Wenn Sie sicher sind, dass die Verwendung von Spinlocks in Ihrem iOS-Projekt eine gute Idee ist, verwenden Sie diese. Bleiben Sie weg vonOSSpinLock! Und implementieren Sie unter keinen Umständen Ihre eigenen Spinlocks in iOS! Verwenden Sie im Zweifelsfall einen Mutex! macOS ist von diesem Problem nicht betroffen, da es einen anderen Thread-Scheduler hat, der es keinem Thread (auch Threads mit niedrigem Prio) erlaubt, während der CPU-Zeit "trocken zu laufen". Dennoch kann dort die gleiche Situation auftreten und führt dann zu einer sehr schlechten Situation Leistung ist daher auch OSSpinLockunter macOS veraltet.