Fädeln Sie einen sicheren Vektor ein

  

das Hinzufügen (push_back) neuer Objekte kann vorherige Zeiger ungültig machen ...

Nein, diese Operation macht vorherige Zeiger nicht ungültig, es sei denn, Sie beziehen sich auf Adressen innerhalb des internen Datenmanagements der Vektoren (was eindeutig nicht Ihr Szenario ist).
Wenn Sie rohe Zeiger oder std::shared_ptr dort speichern, werden diese einfach kopiert und nicht ungültig.

Wie in den Kommentaren erwähnt, ist a std::vector aus mehreren Gründen nicht sehr geeignet, die Thread-Sicherheit für Erzeuger- / Verbrauchermuster zu garantieren. Das Speichern roher Zeiger, um die aktiven Instanzen zu referenzieren, ist nicht!

Eine Warteschlange wird es viel besser unterstützen. Was die Standards betrifft, können Sie std::deque für den Producer / Consumer verwenden, um ceratain Zugriffspunkte ( front() , back() ) zu haben.

Um den Thread dieses Zugriffspunkts sicher zu machen (um Werte zu pushen / zu puffen), können Sie ihn einfach in Ihre eigene Klasse einfügen und einen Mutex verwenden, um Einfüge- / Löschvorgänge für die gemeinsame Warteschlangenreferenz zu sichern Der andere (und wichtige, wie bei Ihrer Frage) Punkt lautet: Eigentümerschaft und Lebensdauer der enthaltenen / referenzierten Instanzen verwalten . Sie können das Eigentumsrecht auch an den Verbraucher übertragen, wenn dies für Ihren Anwendungsfall geeignet ist (also von overhead mit z. B. std::unique_ptr abgehen), siehe unten ...

_{Zusätzlich können Sie einen Semaphor (Bedingungsvariable) haben, um dem Consumer-Thread mitzuteilen, dass neue Daten verfügbar sind.}

  

'1. Atomare oder Mutexe zu verwenden ist nicht genug? Wenn ich von einem Thread zurückdränge, kann ein anderer Thread, der ein Objekt über einen Zeiger behandelt, am Ende ein ungültiges Objekt haben? '

Die Lebensdauer (und damit die Thread-sichere Verwendung) der Instanzen, die in der Warteschlange (gemeinsam genutzter Container) gespeichert sind, müssen getrennt verwaltet werden (z. B. mit intelligenten Zeigern wie std::shared_ptr oder std::unique_ptr dort gespeichert) .

  

'2. Gibt es eine Bibliothek ...?

Es kann alles gut mit den vorhandenen Standard-Bibliothek Mechanismen IMHO erreicht werden.

Siehe Punkt 3. Siehe oben. Was ich dazu noch sagen kann, es klingt so, als würden Sie nach etwas wie einem rw_lock mutex fragen. Sie können dafür einen Ersatz mit einer geeigneten Bedingungsvariablen bereitstellen.

Fühlen Sie sich frei, nach mehr Klarheit zu fragen ...

Wenn Sie dem Container immer nur neue Elemente hinzufügen und dann darauf zugreifen, können Sie einen Vektor mit einer anderen Indirektion finden, so dass anstelle des internen Puffers für einen größeren der einmal zugewiesene Speicherplatz verwendet wird nie befreit und ein neuer Raum wird nur irgendwie thread-sicher angehängt.

Zum Beispiel kann es so aussehen:

Die Klasse enthält ein festes Array von Zeigern auf einzelne Speicherbereiche mit den Elementen, wobei die Größe exponentiell zunimmt. Hier ist die Grenze 6 Teile, also 63000 Artikel - aber das kann leicht geändert werden.

Der Container beginnt damit, dass alle Teilezeiger auf NULL gesetzt sind. Wenn ein Element hinzugefügt wird, wird der erste Chunk mit der Größe m_baseSize , hier 1000, erstellt und in m_parts[0] gespeichert. Nachfolgende Elemente werden dort geschrieben.

Wenn der Chunk voll ist, wird ein weiterer Puffer zugewiesen, der doppelt so groß ist wie der vorherige (2000), und in m_parts[1] gespeichert. Dies wird nach Bedarf wiederholt.

All dies kann mit atomaren Operationen gemacht werden, aber das ist natürlich schwierig. Es kann einfacher sein, wenn alle Schreiber durch einen Mutex geschützt werden können und nur Leser vollständig gleichzeitig sind (z.B. wenn das Schreiben eine viel seltenere Operation ist). Alle Leser-Threads sehen immer entweder NULL in m_parts[i] oder NULL in einem der Puffer oder einen gültigen Zeiger. Vorhandene Elemente werden niemals im Speicher verschoben, ungültig gemacht oder sonstwie.

Soweit es bestehende Bibliotheken betrifft, könntest du Thread-Bausteine ​​ von Intel sehen, insbesondere die Klasse concurrent_vector . Angeblich hat es diese Eigenschaften:

• Zufälliger Zugriff nach Index. Der Index des ersten Elements ist Null.
• Mehrere Threads können den Container erweitern und neue Elemente gleichzeitig anhängen.
• Durch das Vergrößern des Containers werden vorhandene Iteratoren oder Indizes nicht ungültig gemacht.

Wenn Sie die Frage erneut lesen, scheint die Situation etwas anders zu sein.

std::vector eignet sich nicht zum Speichern von Objekten , auf die Sie Referenzen beibehalten müssen, da ein push_back alle Verweise auf die gespeicherten Objekte ungültig machen kann. Aber Sie speichern eine Menge std::shared_ptr .

Die std::shared_ptr s, die darin gespeichert sind, sollten die Größenänderung korrekt handhaben (sie werden verschoben, aber nicht die Objekte, auf die sie zeigen), solange Sie in den Threads keine Referenzen auf std::shared_ptr s gespeichert haben der Vektor, aber Sie behalten Kopien von ihnen.

Bei Verwendung von std::vector und std::deque müssen Sie den Zugriff auf die Datenstruktur synchronisieren, da ein push_back , obwohl nicht referenzvalidierend, die internen Strukturen von deque verändert und somit nicht erlaubt ist um gleichzeitig mit einem Deque-Zugriff zu laufen.

OTOH, std::deque ist aus Performance-Gründen wahrscheinlich ohnehin besser geeignet; Bei jeder Größenänderung bewegen Sie sich um eine Menge von std::shared_ptr , die im Falle eines Kopierens / Löschens einen gesperrten Inkrement / Dekrement zum Refcount machen müssen (wenn sie verschoben werden - wie sie sollten - sollte dies weggelassen werden - aber < a href="https://stackoverflow.com/a/10953951/214671"> YMMV ).

Am wichtigsten ist jedoch, dass wenn Sie std::shared_ptr nur dazu verwenden, die möglichen Bewegungen im Vektor zu vermeiden, können Sie sie vollständig löschen, wenn Sie deque verwenden, da die Referenzen nicht ungültig sind, sodass Sie Ihre Objekte speichern können direkt in deque , anstatt die Heap-Zuweisung und die Indirektion / den Overhead von std::shared_ptr zu verwenden.