Отображение памяти, виртуальная и физическая память в C++

Я пытаюсь решить следующую проблему: имея пользовательский контейнер данных, который управляет универсальным типом, мне нужно разрешить другим компонентам приложения извлекать внутренний указатель контейнера и использовать его, как если бы это была простая область массива T* (без его обработки как более интеллектуальный держатель массива). Проблема в том, что эта память в особом случае перемещается в другое место и стирается. Таким образом, существует множество компонентов, которые знают о старом указателе данных и будут использовать его для доступа к необходимой им информации.

Установка выглядит псевдокодово примерно так:

container<T>
{ 
  T* ptr;
  public:
  ContainerInterfaceCode..
}

Гипотеза:

T* ptr — это псевдоадрес (можно назвать его «виртуальным»?), который отображается в физическом пространстве A.

Когда возникает событие, отображение T* ptr будет установлено для другого физического пространства, B.

Любой компонент, использующий T* ptr, не замечает изменения физического местоположения, «думая», что его данные хранятся по этому виртуальному адресу.

Вывод:

Поэтому я хотел бы знать, есть ли механизм, включающий отображение памяти (виртуальной в физическую), который позволит жонглировать отображением T* ptr, оставляя другие компоненты приложения нетронутыми. Проще говоря, T* ptr должен указывать на область памяти, которая отображается в определенной части, и, по запросу, тот же самый указатель будет отображаться в другом месте (где базовые данные должны быть скопированы для согласованности). Это должно обеспечивать плавные переходы.

Примечание. Я не могу использовать обертки, интеллектуальные указатели, дескрипторы и т. д. по той простой причине, что это означает изменение огромной кодовой базы только для одной, довольно незначительной модификации.

Поскольку я не нашел достаточно ресурсов, посвященных этому сценарию, может ли кто-нибудь представить краткую вебографию с некоторыми соответствующими материалами для чтения по этому вопросу?


person teodron    schedule 26.07.2013    source источник
comment
Я не уверен, что понял вопрос, но я хочу сказать, что это невозможно.   -  person brian beuning    schedule 26.07.2013
comment
отредактирую вопрос с маленькой цифрой   -  person teodron    schedule 26.07.2013
comment
механизм, включающий отображение памяти (виртуальное в физическое)?   -  person HAL    schedule 26.07.2013
comment
@HAL: функция OSMapMemory(), упомянутая в этой теме osdir. com/ml/linux.drivers.modem.hcf/2002-07/msg00005.html звучит как потенциальное решение для моего гипотетического сценария. Вот почему у меня возникло ощущение, что такая вещь действительна и может быть реализована на C++... но у меня нет другого выхода.   -  person teodron    schedule 26.07.2013
comment
@teodron Два разных виртуальных адреса могут относиться к одной и той же физической памяти. Это то, что вы спрашиваете?   -  person brian beuning    schedule 26.07.2013


Ответы (1)


В Linux вы можете использовать общую память. Общая память — это механизм, который позволяет двум процессам обращаться к одной и той же области памяти, это своего рода метод IPC. Более подробную информацию можно найти здесь http://en.wikipedia.org/wiki/Shared_memory.

person cloud    schedule 26.07.2013
comment
В случае нескольких процессов (я использовал общую память для IPC вместо сокетов, так как это было быстрее) это решение. У меня есть один процесс с несколькими компонентами (так что, в основном, одно и то же адресное пространство). Следовательно, ваше решение может не работать (поскольку оно на самом деле не оставляет сам указатель данных неизменным). - person teodron; 26.07.2013
comment
Поскольку у вас есть несколько компонентов, поэтому, если вы хотите использовать общую память, вы должны управлять памятью самостоятельно, например, создавать массив или другую структуру, и вы должны использовать семафор для защиты памяти, чтобы избежать записи двух процессов за один раз. . Другой даже разделяемая память быстрее, чем сокет, но с ней сложнее обращаться, я предпочитаю делать это с сокетом, потому что он более стабилен и прост в использовании. - person cloud; 26.07.2013
comment
сделать это невозможно без какого-либо дескриптора/умного указателя и специализированного менеджера/наблюдателя, чтобы отслеживать все указатели, указывающие на ту же память, что и T* ptr моего контейнера. Такой механизм намного слишком сложен и требует большого внимания к деталям и ноу-хау. Я надеялся избежать этого, поскольку это также означает внесение массовых изменений в огромную кодовую базу, которую необходимо поддерживать каждый день. - person teodron; 26.07.2013
comment
В моем предыдущем проекте мы создали rb-дерево в разделяемой памяти для управления памятью и используем сервалные семафоры для ее защиты от многократной записи. - person cloud; 26.07.2013