Инстанцирование объектов в общей памяти C++

У нас есть потребность в нескольких программах для вызывания функций в общей библиотеке. Доступ библиотечных функций и обновление общая глобальная память. Вызовы функции каждой программы должны видеть эту общую глобальную память. Это - потребности вызова функции видеть обновления любого предшествующего вызова функции даже если названный из другой программы. Поскольку совместимость обосновывает, что у нас есть несколько конструктивных ограничений на то, как функции, выставленные общей библиотекой, должны работать:

• Любые элементы данных (и стандартные типы данных и объекты), которые объявляются глобально, должны быть видимы всем вызывающим сторонам независимо от потока, в котором работает код.
• Любые элементы данных, которые объявляются локально в функции, только видимы в той функции.
• Любой стандартный тип данных или экземпляр любого класса могут появиться или локально или глобально или оба.

Одно решение состоит в том, чтобы поместить общую глобальную память библиотеки в именованную общую память. Первый вызов библиотеки создал бы именованную общую память и инициализировал бы ее. Последующие вызовы программы получили бы адрес общей памяти и использовали бы его в качестве указателя на глобальную структуру данных. Экземпляры объектов, объявленные глобально, должны были бы быть динамично выделены в общей памяти, в то время как экземпляры объектов, заявленные локально, могли быть помещены в стек или в локальной "куче" потока вызывающей стороны. Проблемы возникают, потому что инициализированные объекты в глобальной памяти могут создать и указать на подобъекты, которые выделяют (новую) дополнительную память. Эти новые выделения также должны быть в общей памяти и замечены всеми вызывающими сторонами библиотеки. Другая сложность является этими объектами, которые содержат строки, файлы, и т.д., могут также использоваться в программе вызова. При объявлении в программе вызова память объекта локальна для программы вызова, не совместно использованной. Таким образом, код объекта должен обработать любой случай. Кажется нам, что решение потребует, чтобы мы переопределили глобальное размещение новые, регулярные новые и операторы delete. Мы нашли дизайн для системы управления памятью, которая похожа на него, будет работать, но мы не нашли фактической реализации. Если бы кто-либо знает о реализации дизайна управления памятью Nathan Myers (http://www.cantrip.org/wave12.html?seenIEPage=1), я ценил бы ссылку на него. Кроме того, если кто-либо знает о другом менеджере по общей памяти, который размещает динамично выделяющие объекты, я хотел бы знать об этом также. Я проверил библиотеки Boost и все другие источники, которые я могу найти, но ничто, кажется, не делает то, в чем мы нуждаемся. Мы предпочитаем не должными быть писать тот сами. Так как производительность и устойчивость важны, было бы хорошо использовать доказанный код. Заранее спасибо за любые идеи/справку.

Спасибо за предложения о библиотеках ATL и OSSP. Я проверяю их теперь, хотя я боюсь, что ATL является также Wincentric, если цель, оказывается Unix.

Еще одна вещь теперь кажется ясной нам. Так как объекты могут быть динамично созданы во время выполнения, схема управления памятью должна смочь выделить дополнительные страницы общей памяти. Это теперь начинает быть похожим на полноценного заменяющего диспетчера памяти "кучи".