Linux API. Исчерпывающее руководство

50.5. Сравнение программных интерфейсов для работы с разделяемой памятью

Мы уже успели рассмотреть разные методики разделения участков памяти между неродственными процессами:

• разделяемые файловые отображения (см. подраздел 45.4.2);

• объекты разделяемой памяти POSIX (которым посвящена данная глава).

Многие замечания, приведенные ниже в этом разделе, в равной степени относятся и к анонимным отображениям (см. раздел 45.7), применяемым для разделения памяти между родственными процессами, связанными вызовом fork().

Ниже перечислены особенности, характерные для обеих методик.

• Они обеспечивают быстрое межпроцессное взаимодействие; для синхронизации доступа к разделяемому участку обычно используется семафор (или аналогичный механизм).

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

• Размещение участков разделяемой памяти внутри виртуального адресного пространства процесса происходит похожим образом. Информация обо всех видах участков разделяемой памяти хранится в файле /proc/PID/maps (доступном только в Linux).

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

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

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

Выбор между двумя этими интерфейсами зависит от того, нужно ли нам постоянное резервное хранилище. В случае положительного ответа лучше выбрать разделяемое файловое отображение. Но, если такое хранилище не требуется, то объекты разделяемой памяти POSIX позволяют избежать дополнительных расходов, связанных с использованием файлов на диске.

50.6. Резюме

Объекты разделяемой памяти POSIX применяются для разделения участков памяти между неродственными процессами и не требуют создания файлов на диске. Для этого вместо вызова open(), который обычно выполняется перед mmap(), используется функция shm_open(). Она создает виртуальный файл в рамках файловой системы, находящейся в памяти; для работы с ним можно задействовать традиционные системные вызовы, рассчитанные на файловые дескрипторы. В частности, чтобы задать размер объекта разделяемой памяти, подойдет вызов ftruncate() (так как изначально размер равен нулю).

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

51. Блокировка файлов

В предыдущих главах мы уже рассматривали различные методики, позволяющие синхронизировать действия разных процессов: сигналы (главы 20 и 22) и семафоры (глава 49). В этой главе мы познакомимся с дополнительными средствами синхронизации, специально предназначенными для работы с файлами.

51.1. Краткий обзор

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

1. Чтение порядкового номера из файла.

2. Использование этого номера для каких-то задач внутри приложения.

3. Инкрементация порядкового номера и запись его обратно в файл.

Проблема заключается вот в чем: при отсутствии механизма синхронизации два процесса могут выполнить вышеописанные действия одновременно, и это приведет к последствиям, проиллюстрированным на рис. 51.1 (подразумевается, что начальное значение порядкового номера равно 1000).

Проблема очевидна: по завершении данных действий файл будет содержать значение 1001 вместо корректного 1002 (это пример состояния гонки). Чтобы избежать такой ситуации, нужен некий вид межпроцессной синхронизации.

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