Instanziieren von Objekten im Shared Memory C ++

Wir benötigen mehrere Programme, um Funktionen in einer gemeinsamen Bibliothek aufzurufen. Die Bibliotheksfunktionen greifen auf einen gemeinsamen globalen Speicher zu und aktualisieren ihn. Die Funktionsaufrufe jedes Programms müssen diesen gemeinsamen globalen Speicher sehen. Das heißt, ein Funktionsaufruf muss die Aktualisierungen eines vorherigen Funktionsaufrufs sehen, selbst wenn er von einem anderen Programm aufgerufen wird. Aus Kompatibilitätsgründen haben wir einige Design-Einschränkungen für die Funktionsweise der Funktionen, die von der gemeinsam genutzten Bibliothek bereitgestellt werden:

• Alle Datenelemente (sowohl Standarddatentypen als auch Objekte), die global deklariert werden, müssen für alle Aufrufer sichtbar sein, unabhängig vom Thread, in dem der Code ausgeführt wird.
• Alle Datenelemente, die lokal in einer Funktion deklariert sind, sind nur innerhalb dieser Funktion sichtbar.
• Jeder Standarddatentyp oder eine Instanz einer Klasse kann entweder lokal oder global oder beides erscheinen.

Eine Lösung besteht darin, den gemeinsamen globalen Speicher der Bibliothek in den benannten gemeinsamen Speicher zu stellen. Der erste Bibliotheksaufruf würde den benannten gemeinsamen Speicher erstellen und initialisieren. Nachfolgende Programmaufrufe würden die Adresse des gemeinsamen Speichers abrufen und sie als Zeiger auf die globale Datenstruktur verwenden. Objektinstanzen, die global deklariert werden, müssen dynamisch im gemeinsam genutzten Speicher zugewiesen werden, während lokal deklarierte Objektinstanzen auf dem Stapel oder im lokalen Heap des aufrufenden Threads platziert werden können. Probleme treten auf, weil initialisierte Objekte im globalen Speicher Unterobjekte erzeugen und anzeigen können, die (neuen) zusätzlichen Speicher zuweisen. Diese neuen Zuweisungen müssen sich auch im gemeinsamen Speicher befinden und von allen Bibliotheksanrufern gesehen werden. Eine weitere Komplikation ist, dass diese Objekte, die Strings, Dateien usw. enthalten, auch im aufrufenden Programm verwendet werden können. Wenn im aufrufenden Programm deklariert, ist der Speicher des Objekts lokal für das aufrufende Programm, nicht freigegeben. Der Code des Objekts muss also mit beiden Fällen umgehen. Es scheint uns, dass die Lösung erfordert, dass wir die globalen Platzierungen für neue, reguläre neue und Löschoperatoren überschreiben. Wir haben einen Entwurf für ein Speicherverwaltungssystem gefunden, der aussieht, als würde er funktionieren, aber wir haben keine tatsächlichen Implementierungen gefunden. Wenn jemand eine Implementierung von Nathan Myers 'Memory Management Design ( Ссылка ) kennt, würde ich mich über einen Link freuen es. Wenn jemand einen anderen Shared-Memory-Manager kennt, der dynamisch allokierende Objekte aufnimmt, würde ich es auch gerne wissen. Ich habe die Boost-Bibliotheken und all die anderen Quellen überprüft, die ich finden kann, aber nichts scheint zu tun, was wir brauchen. Wir bevorzugen es, nicht selbst schreiben zu müssen. Da Leistung und Robustheit wichtig sind, wäre es gut, bewährten Code zu verwenden. Vielen Dank im Voraus für jede Idee / Hilfe.

Danke für die Vorschläge zu den ATL- und OSSP-Bibliotheken. Ich überprüfe sie jetzt, obwohl ich befürchte, dass ATL zu Wincentric ist, wenn sich herausstellt, dass das Ziel Unix ist.

Eine andere Sache scheint uns jetzt klar zu sein. Da Objekte während der Ausführung dynamisch erstellt werden können, muss das Speicherverwaltungsschema in der Lage sein, zusätzliche Seiten mit gemeinsam genutztem Speicher zuzuweisen. Dies fängt jetzt an, wie ein ausgewachsener Heap-Ersatz-Speichermanager auszusehen.