Spinlocks, wie nützlich sind sie?

Question

Wie oft verwenden Sie tatsächlich Spinlocks in Ihrem Code? Wie häufig kommt es vor, dass die Verwendung einer Busy-Loop die Verwendung von Sperren übertrifft?
Wenn ich persönlich einen Code schreibe, der Threadsicherheit erfordert, neige ich dazu, ihn mit verschiedenen Synchronisationsprimitiven zu vergleichen, und soweit es geht, scheint die Verwendung von Sperren eine bessere Leistung als die Verwendung von Spinlocks zu bringen. Unabhängig davon, wie lange ich die Sperre tatsächlich halte, ist die Menge an Konflikten, die ich bei der Verwendung von Spinlocks erhalte, weitaus größer als die Menge, die ich bei der Verwendung von Sperren erhalte (natürlich führe ich meine Tests auf einer Multiprozessormaschine durch).

Mir ist klar, dass es wahrscheinlicher ist, in "Low-Level"-Code auf ein Spinlock zu stoßen, aber mich interessiert, ob Sie es auch in einer High-Level-Programmierung nützlich finden?

Answer 1

Wenn Sie leistungsrelevanten Code haben y Sie haben festgestellt, dass es schneller sein muss, als es derzeit ist y Sie haben festgestellt, dass der kritische Faktor die Sperrgeschwindigkeit ist, dann wäre es eine gute Idee, ein Spinlock zu versuchen. In anderen Fällen: Warum sich die Mühe machen? Normale Sperren sind einfacher richtig zu verwenden.

Answer 2

Bitte beachten Sie die folgenden Punkte:

1. Die meisten Mutexe-Implementierungen spinnen für eine kurze Zeit, bevor der Thread tatsächlich außerplanmäßig wird. Aus diesem Grund ist es schwierig, diese Mutexe mit reinen Spinlocks zu vergleichen.

2. Mehrere Threads, die "so schnell wie möglich" auf denselben Spinlock zugreifen, verbrauchen die gesamte Bandbreite und verringern die Effizienz Ihres Programms drastisch. Sie müssen eine winzige "schlafende" Zeit hinzufügen, indem Sie noop in Ihre Spinning-Schleife einfügen.

Answer 3

Sie brauchen Spinlocks im Anwendungscode fast nie zu verwenden, wenn überhaupt, sollten Sie sie vermeiden.

Mir fällt kein Grund ein, ein Spinlock in c#-Code zu verwenden, der auf einem normalen Betriebssystem läuft. Busy Locks sind meist eine Verschwendung auf der Anwendungsebene - die Spinnerei kann dazu führen, dass Sie die gesamte CPU-Zeitscheibe, vs eine Sperre wird sofort einen Kontextwechsel verursachen, wenn nötig.

High-Performance-Code, wo Sie nr von Threads = nr von Prozessoren / Kerne könnte in einigen Fällen profitieren, aber wenn Sie brauchen Performance-Optimierung auf dieser Ebene Ihre wahrscheinlich machen next gen 3D-Spiel, arbeiten auf einem eingebetteten Betriebssystem mit schlechten Synchronisation Primitive, die Schaffung eines OS/Treiber oder in jedem Fall nicht mit c #.

Answer 4

Ich habe Spinlocks für die Stop-the-world-Phase des Garbage Collectors in meiner HLVM Projekt, weil sie einfach sind und das ist ein Spielzeug VM. Allerdings können Spinlocks in diesem Zusammenhang kontraproduktiv sein:

Einer der Perf-Bugs im Garbage Collector des Glasgow Haskell Compilers ist so ärgerlich, dass er einen Namen hat, den " letzte Kernverlangsamung ". Dies ist eine unmittelbare Folge der unangemessenen Verwendung von Spinlocks in ihrer GC und wird unter Linux aufgrund seines Schedulers noch verschärft, aber der Effekt ist tatsächlich immer dann zu beobachten, wenn andere Programme um CPU-Zeit konkurrieren.

Der Effekt ist in der zweiten Grafik deutlich zu erkennen aquí und kann mehr als nur den letzten Kern betreffen aquí , wo das Haskell-Programm bereits ab 5 Kernen Leistungseinbußen verzeichnet.

Answer 5

Behalten Sie diese Punkte bei der Verwendung immer im Hinterkopf Spinlocks :

• Schnelle Ausführung im Benutzermodus.
• Synchronisiert Threads innerhalb eines einzelnen Prozesses oder mehrerer Prozesse, wenn diese einen gemeinsamen Speicher nutzen.
• Kehrt erst zurück, wenn das Objekt Eigentum ist.
• Unterstützt keine Rekursion.
• Verbraucht 100% der CPU, während er "wartet".

Ich habe persönlich so viele Deadlocks gesehen, nur weil jemand dachte, es wäre eine gute Idee, Spinlock zu verwenden.

Seien Sie sehr, sehr vorsichtig bei der Verwendung von Spinlocks

(Ich kann das nicht genug betonen).