В виртуальной памяти два разных процесса могут иметь один и тот же адрес?

Это вопрос интервью, который я нашел на веб-сайте, на вопросы: "В виртуальной памяти два разных процесса имеют один и тот же адрес? Когда вы отвечаете" Нет ", что правильно, как один процесс может получить доступ к другому процессу", памяти, например, отладчик может получить доступ к переменным и изменить их при отладке? "

Я понимаю:

  • 2 diff-процесс может иметь одинаковый адрес виртуальной памяти. Это связано с тем, что каждый процесс имеет свою собственную таблицу страниц. Каждый процесс считает его памятью 4 ГБ на 32-битной машине. Таким образом, оба P1 и P2 могут обращаться к адресу 0xabcdef, но физическое расположение памяти может отличаться. Разве это не так?

  • Отладчик работает по тому же принципу - 2 процесса могут получить доступ к одному и тому же адресу. Таким образом, он может изменять переменные и т.д. На лету.

Ответ 1

1)

  • Одинаковый адрес физической памяти одновременно: НЕТ
  • Один и тот же адрес виртуальной памяти в одно и то же время: ДА (каждый из них соответствует физическому адресу или сети подкачки)

2) Я думаю, что отладчики не обращаются напрямую к другому отлаженному процессу, а связываются со средой выполнения в отлаженном процессе, чтобы внести эти изменения.

Тем не менее, может быть, ОС или инструкции процессора предоставляют доступ/изменяют доступ к другой памяти, если у вас есть права. Это не означает, что он имеет один и тот же адрес, он только говорит, что процесс 1 может сказать "доступ к памяти @address1 в Process2". Кто-то (процессор/ОС/среда выполнения) сделает это для процесса 1.

Ответ 2

Теоретически каждому процессу, выполняемому пользователем в любых существующих популярных ОС (Win, Linux, Unix, Sol и т.д.), Изначально разрешено использовать диапазон адресов 4 ГБ (0x00000000 t0 0xffffffff на 32-битной платформе), будь то простая программа hello world или ее Сложный веб-контейнер, размещающий сайт stackoverflow. Это означает, что каждый процесс имеет свой диапазон, начиная с одного и того же начального адреса и заканчивая тем же адресным пространством ВИРТУАЛЬНО. Очевидно, что каждый процесс имеет одинаковые виртуальные адреса в соответствующем диапазоне виртуального адресного пространства. Так что ответ на свой первый вопрос - ДА.

Разница возникает, когда ОС выполняют какой-либо процесс, современные ОС являются многозадачными ОС и в любой момент времени они выполняют больше, чем процесс. Таким образом, размещение 4 ГБ каждого процесса в основной памяти вообще невозможно. Таким образом, операционные системы используют систему подкачки, в которой они делят диапазон виртуальных адресов (от 0x00000000 до 0xffffffff) на страницу размером 4 КБ (не всегда). Поэтому перед запуском процесса он на самом деле загружает необходимые страницы, необходимые в начальный момент времени, в основную память, а затем загружает другие виртуальные диапазоны страниц по мере необходимости. Поэтому загрузка виртуальной памяти в физическую память (основную память) называется отображением памяти. В этом процессе вы сопоставляете диапазон виртуальных адресов страницы с диапазоном физических адресов (например, диапазон адресов виртуальных адресов от ox00000000 до ox00001000 с диапазоном физических адресов от 0x00300000 до 0x00301000) на основе свободного места в основной памяти. Так что в любой момент времени только один виртуальный адрес диапазон будет сопоставлен с конкретным диапазоном физических адресов, поэтому ответ на второй вопрос - НЕТ.

НО

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

Например, в Linux для каждого исполняемого файла требуется, чтобы библиотека libc.so выполняла исполняемый файл программы. Каждый процесс загружает необходимые библиотеки и выделяет им некоторые диапазоны виртуальных адресов в своем адресном пространстве. итак, рассмотрим сценарий, в котором вы выполняете 100 процессов, где каждому процессу требуется эта библиотека libc.so. Поэтому, если ОС выделяет виртуальное адресное пространство в каждом процессе для этой библиотеки libc.so, тогда вы можете представить уровень дублирования для библиотеки libc.so & Вполне возможно, что в любой момент времени вы получите несколько экземпляров страниц диапазона адресов libc.so в основной памяти. Чтобы создать избыточную ОС, загрузите libc.so в определенный диапазон виртуального адресного пространства каждого процесса, который сопоставлен с фиксированный диапазон физических адресов в основной памяти. Поэтому каждый процесс будет ссылаться на этот фиксированный диапазон физических адресов для выполнения любого кода в libc.so. Таким образом, в этом случае каждый процесс имеет несколько физических диапазонов адресов.

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

Надеюсь, это поможет.

Ответ 3

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

Ответ 4

Иногда я чувствую себя "старшим" в рекламе Minolta... В 1960 году Multics был создан с использованием виртуальной памяти. Последняя система Multics была закрыта 30 октября 2000 года в 17:00.

В Multics в памяти присутствовала только одна копия любой программы, независимо от того, сколько пользователей ее запускали. Это означает, что каждый пользовательский процесс имел одинаковый физический и виртуальный адрес для программы.

Когда я смотрю на диспетчер задач Windows и вижу несколько копий программы (например, svchost.exe), я удивляюсь, почему/как были потеряны революционные концепции в Multics.

Ответ 5

Каждый процесс имеет адресное пространство 4 ГБ в 32-битной системе. Где этот реальный 4GB управляется ОС. Таким образом, в принципе 2 разных процесса могут иметь одинаковые адреса, которые являются локальными для процесса.

Теперь, когда один процесс должен читать память другого процесса, он должен либо взаимодействовать с другим процессом (файлы с отображением памяти и т.д.), либо использовать Apache Debug, например OpenProcess/ReadProcessMemory.

Я уверен, что один процесс не может напрямую перейти и прочитать виртуальную память другого процесса по крайней мере в Win32 без помощи ОС.