Това всъщност не е проблем.
Да, друг процес може да промени файла, докато го картографирате, и да, възможно е да видите модификациите. Дори е вероятно, тъй като почти всички операционни системи имат унифицирани системи за виртуална памет, така че освен ако не се изисква небуферирано писане, няма начин да се пише без да се мине през буферния кеш и няма начин без някой да държи картографиране виждам промяната.
Това дори не е нещо лошо. Всъщност би било по-притеснително, ако не можете да видите промените. Тъй като файлът квази става част от вашето адресно пространство, когато го картографирате, има смисъл да виждате промени във файла.
Ако използвате конвенционален I/O (като read
), някой все още може да модифицира файла, докато го четете. Казано по друг начин, копирането на файлово съдържание в буфер на паметта невинаги е безопасно при наличие на модификации. Той е „безопасен“, доколкото read
няма да се срине, но не гарантира, че вашите данни са последователни.
Освен ако не използвате readv
, нямате никакви гаранции относно атомарността (и дори с readv
нямате гаранция, че това, което имате в паметта, е съвместимо с това, което е на диска, или че не се променя между две извиквания на readv
). Някой може да модифицира файла между две read
операции или дори докато сте в средата му.
Това не е нещо, което не е официално гарантирано, но „вероятно все още работи“ – - напротив, напр. под Linux записите доказано не са атомарни. Дори не случайно.
Добрата новина:
Обикновено процесите не просто отварят произволен произволен файл и започват да пишат в него. Когато се случи подобно нещо, обикновено това е или добре познат файл, който принадлежи на процеса (напр. лог файл), или файл, който изрично сте указали на процеса да пише (напр. запис в текстов редактор), или процесът създава нов файл (напр. компилаторът създава обектен файл) или процесът просто добавя към съществуващ файл (напр. db журнали и, разбира се, лог файлове). Или процесът може атомарно да замени файл с друг (или да прекрати връзката му).
Във всеки случай целият плашещ проблем се свежда до „няма проблем“, защото или сте наясно какво ще се случи (така че отговорността е ваша), или работи безпроблемно, без да се намесва.
Ако наистина не харесвате възможността друг процес може евентуално да пише във вашия файл, докато сте го картографирали, можете просто да пропуснете FILE_SHARE_WRITE
под Windows, когато създавате манипулатора на файла. POSIX го прави донякъде по-сложно, тъй като трябва да fcntl
дескриптора за задължително заключване, което не е необходимо да се поддържа или да е 100% надеждно на всяка система (например под Linux).
person
Damon
schedule
22.01.2014
MAP_PRIVATE
. Това не означава дайте ми лично копие, а означава, че извършените от мен модификации са лични за мен. Има същите проблеми с паралелността като всеки друг метод за достъп до файл - person Petesh   schedule 22.01.2014MAP_PRIVATE
означава дай ми лично копие? Всъщност цитирах частта от спецификацията, в която се посочва обратното. Би било хубаво обаче, ако имаше опция, която действително гарантира, че картографираните страници не се променят от други процеси, след като са били достъпни. - person Stephan Tolksdorf   schedule 22.01.2014FILE_SHARE_READ
, така че други процеси да не могат да променят файла, докато го използвате. - person Harry Johnston   schedule 23.01.2014