Wir brauchen 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 anzeigen. Dies ist ein Funktionsaufruf, der die Aktualisierungen aller vorherigen Funktionsaufrufe anzeigen muss, auch wenn diese von einem anderen Programm aufgerufen wurden. Aus Kompatibilitätsgründen gelten verschiedene Einschränkungen hinsichtlich der Funktionsweise der von der gemeinsam genutzten Bibliothek bereitgestellten Funktionen:

Alle global deklarierten Datenelemente (sowohl Standarddatentypen als auch Objekte) müssen für alle Aufrufer sichtbar sein, unabhängig davon, in welchem ​​Thread 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 angezeigt werden.

Eine Lösung besteht darin, den allgemeinen globalen Speicher der Bibliothek im benannten gemeinsamen Speicher abzulegen. Der erste Bibliotheksaufruf erstellt den benannten gemeinsamen Speicher und initialisiert ihn. Nachfolgende Programmaufrufe würden die Adresse des gemeinsam genutzten Speichers erhalten und als Zeiger auf die globale Datenstruktur verwenden. Global deklarierte Objektinstanzen müssten dynamisch im gemeinsam genutzten Speicher zugewiesen werden, während lokal deklarierte Objektinstanzen auf dem Stapel oder im lokalen Heap des aufrufenden Threads abgelegt werden könnten. Probleme treten auf, weil initialisierte Objekte im globalen Speicher Unterobjekte erstellen und auf diese verweisen können, die (neuen) zusätzlichen Speicher zuweisen. Diese neuen Zuordnungen müssen sich auch im gemeinsamen Speicher befinden und von allen Aufrufern der Bibliothek gesehen werden. Eine weitere Komplikation besteht darin, dass diese Objekte, die Zeichenfolgen, Dateien usw. enthalten, auch im aufrufenden Programm verwendet werden können. Wenn das Objekt im aufrufenden Programm deklariert ist, befindet es sich lokal im aufrufenden Programm und wird nicht gemeinsam genutzt. Der Code des Objekts muss also beide Fälle behandeln. Es scheint uns, dass die Lösung erfordert, dass wir die Operatoren "Globales Placement neu", "Regelmäßig neu" und "Löschen" überschreiben. Wir haben ein Design für ein Speicherverwaltungssystem gefunden, das so aussieht, als würde es funktionieren, aber wir haben keine tatsächlichen Implementierungen gefunden. Wenn jemand von einer Implementierung des Speicherverwaltungsdesigns von Nathan Myers weiß (http://www.cantrip.org/wave12.html?seenIEPage=1) Ich würde mich über einen Link freuen. Wenn jemand einen anderen Shared-Memory-Manager kennt, der die dynamische Zuweisung von Objekten ermöglicht, würde ich auch gerne davon erfahren. Ich habe die Boost-Bibliotheken und alle anderen Quellen, die ich finden kann, überprüft, aber nichts scheint zu tun, was wir brauchen. Wir möchten lieber nicht selbst schreiben müssen. Da Leistung und Robustheit wichtig sind, wäre es schön, bewährten Code zu verwenden. Vielen Dank im Voraus für alle Ideen / Hilfe.

Vielen Dank für die Vorschläge zu den ATL- und OSSP-Bibliotheken. Ich überprüfe sie jetzt, obwohl ich befürchte, dass ATL zu winzig 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 gemeinsam genutzte Speicherseiten zuzuweisen. Dies sieht nun aus wie ein ausgewachsener Heap-Ersatz-Speichermanager.