std::list thread_safety

Ich wollte herausfinden, ob die Listen wurden thread-sicher im Allgemeinen, so fragte ich, und diesen thread gefunden. Die Schlussfolgerung, die ich habe, ist, dass, in der aktuellen Implementierung von std::list in gcc libstdc++, können Sie sicher ändern Sie die Liste in einen thread und beliebig iterieren durch Listen gleichzeitig, aber wage es nicht zwei threads ändern der gleichen Liste (ohne syncronization). Darüber hinaus ist dieses Verhalten sollte nicht werden, abhängt. Ich habe Riss der code der Bibliothek darauf hin, die Probleme in etwas mehr detail. Ich hoffe, dass es hilfreich ist.

Zuerst beginnen wir mit der Allgemeinen Frage des thread-Sicherheit für Listen. Ich dachte, es wäre schön, zu "beweisen", dass die Listen, die unsicher sind, durch das Beispiel, so warf ich den folgenden code zusammen.

#include <iostream>
#include <list>
#include <mutex>
#include <thread>

using namespace std;

list<int> unsafe_list;

class : public list<int> {
  mutex m;
  public:
  void push_back(int i) {
    lock_guard<mutex> lock{m};
    list<int>::push_back(i);
  }
} safe_list;

template <typename List> void push(List &l) {
  for (auto i = 0; i < 10000; ++i)
    l.push_back(0);
}

void report_size(const list<int> &li, char const *name) {
  size_t count{};
  for (auto && i : li) ++count;
  cout << name << endl;
  cout << "size() == " << li.size() << endl;
  cout << "count  == " << count << endl;
}

int main() {
  auto unsafe = []() { push(unsafe_list); };
  auto safe = []() { push(safe_list); };
  thread pool[]{
      thread{unsafe}, thread{unsafe}, thread{unsafe},
      thread{safe},   thread{safe},   thread{safe},
  };
  for (auto &&t : pool)
    t.join();
  report_size(unsafe_list, "unsafe_list");
  report_size(safe_list, "safe_list");
}

Die Ausgabe, die ich bekam war:

unsafe_list
size() == 19559
count  == 390
safe_list
size() == 30000
count  == 30000

Huch. Das bedeutet, dass kaum Elemente, schob ich landete auf der Liste. Aber es ist schlimmer als das! Es ist nicht nur nicht das Recht haben, die Anzahl der Elemente, es denkt, es hat eine andere Nummer, als es eigentlich tut, und dass die Anzahl ist nicht das, was ich möchte! Während das bedeutet, dass es fast schon ein Speicher-Leck, bei mir lief es mit valgrind die Operationen erfolgreich abgeschlossen. Ich habe gehört, dass valgrind und andere tools können weniger, als hilfreich, wenn Sie versuchen umzugehen mit Parallelität, ich denke, dies ist der Beweis dafür.

Zuerst habe ich versucht, schieben 10 Elemente gleichzeitig oder so, aber passiert ist nichts faul. Ich dachte mir, dass es die Verwaltung zu schieben, alles in seiner time slice, also ich konnte es auf 10000 und bekam die Ergebnisse, die ich wollte. Nur ein Hinweis für jeden, der versucht zu duplizieren das experiment, es kann funktionieren oder auch nicht-je nach system-Konfiguration und scheduling-Algorithmus, etc.

Angesichts der Art der verknüpften Listen, ich hatte erwartet, ein solches experiment in einem seg-fault oder sonst beschädigt Liste. Ein seg-fault, wäre eine Gnade, wenn dies war der Grund für einige Fehler, die Sie gesucht haben.

Was zum Teufel ist Los

Hier werde ich erklären, was genau passiert ist und warum (oder zumindest eine sehr plausible Erklärung). Wenn Sie noch nicht initialisiert sind, um concurrency-Probleme, sollten Sie diese ein intro. Wenn Sie ein Experte sind, bitte sagen Sie mir, wo bin ich falsch oder unvollständig sind.

War ich neugierig, so dass ich schaute auf die gcc libstdc++ - Implementierung. Um zu erklären das beobachtete Verhalten, eine kurze Erklärung, wie die Liste funktioniert, ist in Ordnung.

Implementierungsdetails

Da ist überhaupt nichts Interessantes oder seltsames über die zugrunde liegende Struktur oder Algorithmus, aber es gibt verschiedene C++ - Implementierung-details, die erwähnt werden müssen. Zunächst werden die Knoten der Liste alle entspringen einer gemeinsamen Basis-Klasse, die speichert nur zwei Zeiger. Auf diese Weise, alle die das Verhalten der Liste gekapselt ist. Der eigentliche Knoten, die andere als die sich aus der Basis, sind Strukturen mit nicht-statischen Daten-member __gnu_cxx::__aligned_membuf<_Tp> _M_storage. Diese Knoten sind bewusst die value_type von der Liste, und leiten sich von der allocator_type rebound zu _List_node<_Tp>. Der Zweck dieser Knoten ist zu erhalten und release-Speicher für die Liste, und verwenden Sie Ihre Basis zu pflegen, die Struktur der Daten. (Ich empfehle dieses Papier für eine Erklärung, wie die Typen sind ausgeklammert für die Benutzung von Iteratoren, es kann etwas Licht auf, warum bestimmte Dinge so umsetzen, wie Sie sind http://www.stroustrup.com/SCARY.pdf. Für die masochistische, sehen Sie dieses Assistenten erklären die schönen Alptraum, der c++ - allocators https://www.youtube.com/watch?v=YkiYOP3d64E). Die Liste kümmert sich dann um Aufbau und Zerstörung, und stellt die Schnittstelle für die Benutzer der Bibliothek, blah, blah, blah.

Einen großen Vorteil, dass eine gemeinsame (Typ-ignorant) Basis-Klasse für die Knoten, die Sie haben können beliebige Knoten miteinander verbunden. Dies ist nicht sehr hilfreich, wenn man mit tollkühner, aber Sie nutzen es in einer kontrollierten Art und Weise. Die "Schwanz-Knoten" ist nicht vom Typ value_type, aber der Typ size_t. Die Schwanz-Knoten nimmt die Größe der Liste! (Es dauerte ein paar Minuten, um herauszufinden, was Los war, aber es war Spaß, also keine große Sache. Der große Vorteil dabei ist, dass jede Liste in Existenz haben kann, die gleiche Art von Schwanz-Knoten, so gibt es weniger code-Duplizierung für den Umgang mit der Rute Knoten und die Liste braucht nur eine nicht-statischen Daten-member zu tun, was es tun muss).

So, wenn ich push einen Knoten auf der Rückseite der Liste, die end() iterator übergeben, die folgende Funktion:

 template<typename... _Args>
   void
   _M_insert(iterator __position, _Args&&... __args)
   {
 _Node* __tmp = _M_create_node(std::forward<_Args>(__args)...);
 __tmp->_M_hook(__position._M_node);
 this->_M_inc_size(1);
   }

_M_create_node() schließlich verwendet die direkt-Zuweisung zu bekommen, der Speicher für die Knoten dann versucht, die Konstruktion eines Elements mit den Argumenten. Der "Punkt" des _M_hook() Funktion ist zu zeigen, Zeiger auf Zeiger, auf die Sie zeigen soll, und ist hier aufgeführt:

void
_List_node_base::
_M_hook(_List_node_base* const __position) _GLIBCXX_USE_NOEXCEPT
{
  this->_M_next = __position;
  this->_M_prev = __position->_M_prev;
  __position->_M_prev->_M_next = this;
  __position->_M_prev = this;
}

Die Reihenfolge, in der die Zeiger manipuliert werden, ist wichtig. Es ist der Grund, warum ich behaupten, dass Sie Durchlaufen können, während die Manipulation der Liste gleichzeitig. Mehr dazu später. Dann die Größe angepasst wird:

void _M_inc_size(size_t __n) { *_M_impl._M_node._M_valptr() += __n; }

Wie gesagt, die Liste hat einen Schwanz Knoten vom Typ size_t, so, wie Sie sich vorstellen können, _M_impl._M_node._M_valptr() ruft einen Zeiger auf diese Zahl, und dann +='s es die richtige Menge.

Das Beobachtete Verhalten

Also, was ist passiert? Die threads sind der Einstieg in eine Daten Rennen (https://en.cppreference.com/w/cpp/language/memory_model) in der _M_hook() und _M_inc_size() Funktionen. Ich kann nicht finden, ein schönes Bild online, so sagen wir, dass T ist der Schwanz, B ist der "zurück," und wir wollen, schieben 1 auf der Rückseite. Das heißt, wir haben die Liste (fragment) B <-> T, und wir wollen B <-> 1 <-> T. Schließlich 1 Anrufe _M_hook auf T, und dann geschieht Folgendes:

1. 1 Punkte nach vorne zu T
2. 1 Punkte nach hinten zu B
3. B Punkte nach vorne zu 1
4. T Punkte nach hinten zu 1

Diese Weise keine Position ist je "vergessen." Jetzt sagen Sie, dass 1 und 2 sind zurück geschoben in verschiedenen threads auf der gleichen Liste. Es ist völlig plausibel, dass die Schritte (1) und (2) komplett für 1, dann 2 wird komplett nach hinten geschoben, dann (1) muss fertig werden. Was passiert in diesem Fall? Wir haben die Liste B <-> 2 <-> T, aber 1 verweist B und T, so dass, wenn Ihre Zeiger sind angepasst, die Liste sieht wie B <-> 1 <-> T, und das ist ein memory leak Sohn.

Soweit Durchlaufen, ist es egal, ob Sie rückwärts oder vorwärts, du wirst immer bekommen, erhöht sich durch die Liste richtig. Dieses Verhalten hat nicht zu sein scheinen, garantiert durch die Norm, jedoch, so dass, wenn die codes dieses Verhalten hängt es zerbrechlich ist.

Was über die Größe???

Okay, also das ist wie Parallelität 101, eine alte Geschichte, wohl besser gesagt, viele Male, ich hoffe, dass es zumindest sehenswert, der code der Bibliothek. Das Größe Problem ist denke ich ein wenig interessanter, und ich habe sicherlich etwas von es herauszufinden.

Im Grunde, weil der Wert erhöht, ist nicht eine "lokale" variable, dessen Wert gelesen werden müssen in ein register Hinzugefügt wird, der Wert, dann wird dieser Wert gespeichert, zurück in die variable. Schauen wir uns einige der Baugruppe (meine assembly-Spiel ist schwach, bitte nicht nett sein, wenn Sie eine Korrektur). Betrachten Sie das folgende Programm:

int i{};
int main() {
  ++i;
}

Wenn ich mit objdump -D auf den Gegenstand, den ich bekommen:

Disassembly of section .text:

0000000000000000 <main>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   8b 05 00 00 00 00       mov    0x0(%rip),%eax        # a <main+0xa>
   a:   83 c0 01                add    $0x1,%eax
   d:   89 05 00 00 00 00       mov    %eax,0x0(%rip)        # 13 <main+0x13>
  13:   b8 00 00 00 00          mov    $0x0,%eax
  18:   5d                      pop    %rbp
  19:   c3                      retq   

4: bewegt sich der Wert von i ins register eax. 0x1 Hinzugefügt eax, dann eax ist wieder zurück in i. So, was hat das zu tun mit Daten, die Rennen? Nehmen Sie einen anderen Blick auf die Funktion, die updates der Größe der Liste:

void _M_inc_size(size_t __n) { *_M_impl._M_node._M_valptr() += __n; }

Ist es vollkommen plausibel, dass die aktuelle Größe der Liste wird in ein register geladen, dann einen anderen thread, in Betrieb sind auf dieser Liste die Schritte auf unserem Betrieb. So, wir haben die alten Werte der Liste in einem register gespeichert, aber wir müssen sparen, der Staat und die transfer control verwenden, um jemand anderes. Vielleicht werden Sie erfolgreich hinzufügen eines Elements in die Liste und aktualisieren Sie die Größe, dann geben uns die Kontrolle zurück. Wir renovieren unser Land, sondern unser Staat ist nicht mehr gültig! Wir haben die alte Größe der Liste, die wir erhöhen, und deren Wert speichern wir wieder in Erinnerung, das vergessen, über den Betrieb dem anderen thread durchgeführt.

Eine Letzte Sache

Wie ich bereits erwähnt habe, ist die "Lokalität" der i ins Spiel kam, in dem oben genannten Programm. Wie wichtig das ist sehen Sie im folgenden:

int main() {
  int i{};
  ++i;
}

Disassembly of section .text:

0000000000000000 <main>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   c7 45 fc 00 00 00 00    movl   $0x0,-0x4(%rbp)
   b:   83 45 fc 01             addl   $0x1,-0x4(%rbp)
   f:   b8 00 00 00 00          mov    $0x0,%eax
  14:   5d                      pop    %rbp
  15:   c3                      retq   

Hier kann es gesehen werden, dass kein Wert gespeichert ist, um ein register und kein register geschoben wird, um einige Variablen. Leider, soweit ich kann sagen, dies ist nicht irgendein netter trick, um zu vermeiden Probleme mit der Parallelität, wie mehrere threads Betriebssystem auf die gleiche variable wird unbedingt haben, darauf zu arbeiten durch memory access, und nicht nur durch die Register. Ich bin schnell raus aus meiner Liga hier, aber ich bin mir ziemlich sicher, dass das der Fall ist. Die nächste beste Sache ist, zu verwenden atomic<int>, aber dieses verdammte Ding ist schon zu lange.