30. Jul 2019
Lesedauer 4 Min.
Lock-freies Multithreading mit atomaren Operationen
Internalpointers
Ein Beitrag von Internalpointers.com erklärt das Synchronisieren von Threads mit Operationen, die direkt von der CPU ausgeführt werden und atomar erfolgen. Hier lesen Sie die Erklärung der Problemstellung, unten gibt's den Link zum englischen Artikel.

Das griechische Wort "Atom" bedeutet unzerlegbar. Eine Aufgabe, die von einem Computer ausgeführt wird, gilt als atomar, wenn sie nicht mehr teilbar ist: Sie kann nicht in kleinere Schritte zerlegt werden. Atomizität ist eine wichtige Eigenschaft von Multithread-Operationen: Da sie unteilbar sind, gibt es keine Möglichkeit, dass ein Thread durch eine atomare Operation gleitet, die gleichzeitig von einer anderen ausgeführt wird. Wenn beispielsweise ein Thread atomar auf gemeinsame Daten schreibt, kann kein anderer Thread die Änderung halbfertig lesen. Umgekehrt, wenn ein Thread atomar aus gemeinsamen Daten liest, sieht er den Wert so, wie er zu einem bestimmten Zeitpunkt erschienen ist. Mit anderen Worten, es besteht keine Gefahr von Datenrennen.Synchronisations-Primitive werden unter anderem verwendet, um Operationen, die sich mit Daten befassen, die über mehrere Threads verteilt sind, Atomizität zu verleihen. Wie? Sie erlauben einfach einem einzelnen Thread, seine gleichzeitige Arbeit zu erledigen, während andere vom Betriebssystem blockiert werden, bis der erste abgeschlossen ist. Die Begründung ist, dass ein blockierter Thread anderen nicht schadet. Aufgrund ihrer Fähigkeit, Threads einzufrieren, werden solche Synchronisations-Primitive auch als Blockiermechanismen bezeichnet. Jeder Blockiermechanismus wird für die überwiegende Mehrheit Ihrer Anwendungen hervorragend funktionieren. Bei richtiger Anwendung sind sie schnell und zuverlässig. Sie führen jedoch einige Nachteile ein, die Sie vielleicht in Betracht ziehen sollten:
- Sie blockieren andere Threads – ein ruhender Thread wartet einfach auf das Wecksignal und tut nichts: Es könnte wertvolle Zeit verschwenden.
- Sie könnten Ihre Anwendung aufhängen – wenn ein Thread, der eine Sperre für eine primitive Synchronisation hält, aus irgendeinem Grund abstürzt, wird die Sperre selbst nie freigegeben und die wartenden Threads bleiben für immer stecken.
- Sie haben wenig Kontrolle darüber, welcher Thread schlafen wird – es liegt in der Regel am Betriebssystem, den zu blockierenden Thread auszuwählen. Dies kann zu einem unglücklichen Ereignis führen, das als Prioritätsumkehr bekannt ist: Ein Thread, der eine sehr wichtige Aufgabe ausführt, wird von einem anderen mit einer niedrigeren Priorität blockiert.