Ich habe nur ein bisschen über dieses Thema gelesen, aber es scheint, dass der einzige Vorteil darin besteht, Konfliktprobleme zu umgehen, aber keinen wichtigen Einfluss auf das Deadlock-Problem haben wird, da der code, der frei von Sperren ist, so klein und grundlegend ist (FIFOs, LIFOs, Hash), dass es nie ein Deadlock-Problem gab.
Also geht es nur um Leistung - ist das richtig?
Ich glaube, ich habe einen Artikel gesehen, der mathematisch bewiesen hat, dass jeder Algorithmus auf eine wartefreie Weise geschrieben werden kann (was im Grunde bedeutet, dass man sich darauf verlassen kann, dass jeder Thread immer Fortschritte auf dem Weg zu seinem Ziel macht). Das bedeutet, dass es auf jede große Anwendung angewendet werden kann (schließlich ist ein Programm einfach ein Algorithmus mit vielen, vielen Parametern) und weil Wartefreiheit sicherstellt, dass weder Deadlocks noch Lebendlocks auftreten (solange es keine Fehler gibt, die sie davon abhalten, wirklich wartefrei zu sein), vereinfacht es diese Seite des Programms. Andererseits ist ein mathematischer Beweis jedoch weit entfernt von der tatsächlichen Implementierung des Codes (soweit ich weiß gibt es nicht einmal eine vollständig lock-freie verkettete Liste, die auf PCs ausgeführt werden kann, ich habe welche gesehen, die die meisten Teile abdecken, aber sie können in der Regel entweder nicht mit einigen gängigen Funktionen umgehen oder einige Funktionen erfordern, dass die Struktur gesperrt wird).
Übrigens habe ich auch einen anderen Beweis gefunden, der zeigte, dass jeder lock-freie Algorithmus tatsächlich als wartefrei betrachtet werden kann, aufgrund der Gesetze der Wahrscheinlichkeit und verschiedener anderer Faktoren.
Skalierbarkeit ist ein wirklich wichtiges Thema in der effizienten Multi-/Many-Core-Programmierung. Der größte Begrenzungsfaktor ist tatsächlich der Abschnitt des Codes, der sequenziell ausgeführt werden sollte (siehe Amdahls Gesetz). Jedoch sind auch Konflikte bei Sperren sehr problematisch.
Ein Lock-freier Algorithmus adressiert das Skalierbarkeitsproblem, das bei herkömmlichen Sperren besteht. Daher könnte man sagen, dass lock-free hauptsächlich für Performance ist, um nicht die Möglichkeit eines Deadlocks zu verringern.
Es ist jedoch zu beachten, dass es mit der aktuellen x86-Architektur unmöglich ist, einen allgemeinen lock-freien Algorithmus zu schreiben. Dies liegt daran, dass wir in der aktuellen x86-Architektur keine atomaren Datenaustausche beliebiger Größe durchführen können (was auch für andere Architekturen außer Sun's ROCK gilt). Daher sind aktuelle lock-free Datenstrukturen ziemlich begrenzt und sehr spezialisiert für bestimmte Verwendungen.
Ich glaube, dass aktuelle lock-free Datenstrukturen in einem Jahrzehnt nicht mehr verwendet werden. Ich erwarte fest, dass eine hardwaregestützte allgemeine lock-free Mechanismus (ja, das ist transactional memory, TM) innerhalb eines Jahrzehnts implementiert wird. Wenn eine Art von TM implementiert ist, obwohl sie die Probleme von Sperren nicht perfekt lösen kann, werden viele Probleme (einschließlich Prioritätsinversion und Deadlock) beseitigt. Die Implementierung von TM in Hardware ist jedoch immer noch sehr anspruchsvoll, und in x86 wurde bisher nur ein Entwurf vorgeschlagen.
Es ist immer noch zu lang: 2 Satz Zusammenfassung.
Lock-freie Datenstruktur ist kein Allheilmittel für die lockbasierte Mehrfadenprogrammierung (sogar TM nicht. Wenn Sie ernsthaft Skalierbarkeit benötigen und Probleme mit Sperrkonflikten haben, sollten Sie eine lock-free Datenstruktur in Betracht ziehen.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
