• Результаты открытия файла в режиме O_RDONLY зависят от того, какой флаг был указан при вызове mmap() — MAP_PRIVATE или MAP_SHARED. В первом случае mmap() поддерживает любые комбинации защиты памяти, поскольку изменения приватной страницы все равно никогда не записываются в исходный файл. Во втором случае с режимом O_RDONLY совместима только защита PROT_READ (PROT_READ | PROT_EXEC). Это логично, ведь защита PROT_WRITE позволяет обновлять отображенный файл.
Ядро автоматически возвращает изменения содержимого отображения типа MAP_SHARED обратно в исходный файл, но по умолчанию нет никаких гарантий относительно того, когда именно произойдет такая синхронизация (стандарт SUSv3 этого не требует).
Системный вызов msync() предоставляет приложению возможность самостоятельно синхронизировать разделяемое отображение с отображенным файлом. Это может пригодиться в разнообразных ситуациях. Например, чтобы гарантировать целостность информации, база данных может сбрасывать изменения на диск с помощью msync(). Выполняя данный вызов, мы делаем обновления изменяемого отображения видимыми для других процессов, которые считывают исходный файл.
#include
int msync(void *
Возвращает 0 при успешном завершении или -1 при ошибке
Аргументы addr и length вызова msync() обозначают начальный адрес и размер участка памяти, который нужно синхронизировать. Адрес должен быть выровнен по странице, а длина округлена до следующего кратного размеру страницы в системе (в стандарте SUSv3 требование к выравниванию является
Аргумент flags может принимать одно из следующих значений:
• MS_SYNC — выполняет синхронную запись в файл. Вызов блокируется, пока все измененные страницы участка памяти не будут записаны на диск;
• MS_ASYNC — выполняет асинхронную запись в файл. Измененные страницы участка памяти записываются на диск не сразу, но немедленно становятся видимыми для других процессов, выполняющих операцию read() для соответствующего участка файла.
Различия между этими двумя значениями можно сформулировать иначе: после операции MS_SYNC участок памяти синхронизирован с диском, тогда как после MS_ASYNC — только с кэшем буфера ядра.
Если после операции MS_ASYNC не предпринять никаких дополнительных действий, то измененные страницы на участке памяти в какой-то момент будут автоматически сброшены на диск потоком выполнения ядра pdflush (в Linux 2.4 и более ранних версиях он назывался kupdated). В Linux существует два (нестандартных) метода ускорить вывод. Вслед за msync() можно сделать вызов fsync() (или fdatasync()), указав дескриптор соответствующего отображения. Данный вызов блокируется до тех пор, пока кэш буфера не будет синхронизирован с диском. Как вариант можно инициировать асинхронную запись страниц с помощью операции posix_fadvise() POSIX_FADV_DONTNEED (в Linux эти два случая имеют некоторые особенности, не описанные в стандарте SUSv3).
В аргументе flags можно указать еще одно дополнительное значение. MS_INVALIDATE — удаляет кэшированные копии отображенных данных. После сброса на диск любых измененных страниц участка памяти те из них, что не соответствуют исходному файлу, помечаются как недействительные. При следующем обращении в них будут скопированы соответствующие участки файла. Как следствие, любые изменения, внесенные в файл другим процессом, становятся доступными на участке памяти.
Как и многие другие современные реализации UNIX, Linux предоставляет так называемую систему
Однако система унифицированной виртуальной памяти не предусмотрена стандартом SUSv3 и присутствует не во всех UNIX-системах. В таких реализациях, чтобы сделать видимыми изменения содержимого отображения для других процессов, читающих файл, необходимо выполнить вызов msync(). И наоборот, чтобы запись в файл, выполненная другим процессом, стала доступной на отображенном участке памяти, необходимо использовать флаг MS_INVALIDATE. Многопроцессные приложения, в которых для работы с одним и тем же файлом применяются как mmap(), так и системные вызовы ввода/вывода, должны корректно выполнять операцию msync(), иначе их нельзя будет перенести в системы, не поддерживающие систему унифицированной виртуальной памяти.