BnW — *блокировки

_ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Полтора года назад (#UIOG94) я привлекал некоторое локальное сообщество к криптографии и никто из них сейчас ее не использует (или не пишет мне). Спасибо тебе, Роскомпозор, что ты заставляешь людей задуматься и пересмотреть свое отношение к инфопространству. Сегодня в течение дня пару человек спросили как обойти блокировки и обезопасить подключение к биткоин-бирже и зашифровать диск. Напомню, если у вас еще нет gpg-ключа - сейчас самое время его создать (лучше сразу GPG2.0 и эллиптические кривые), вангую, в скором будущем вам это тоже потребуется наряду с умением настроить прокси/впн/вдс с опенвпн. -----BEGIN PGP SIGNATURE----- iMsEARMKADEWIQS8yW2gSDhmrARXjkIsjs0AO3ulYgUCWtTanBMcamVydW5tYW5A Z21haWwuY29tAAoJECyOzQA7e6Vi/JACB2QytIJVVruLZNyQbuui/k4dOr/hzGxO 2o0cv+4dm3Gy/21fntAa/meHltb3QtDKFRDUhlwbysqiNnc2W4IILve0Aginl6lx OFFOXG51dEoQsLqhCz/zlLaBQTGEZbBgsTSELTRhEWjqzhN1K/zm9OA7v1C6ElBe YQhmhQ4DtlHhRRvGwg== =n4b3 -----END PGP SIGNATURE-----

Давайте обсосем одну задачку. Имеем линукс, имеем фс, имеем два и больше процессов и один файл. Необходимо синхронизировать процессы для доступа в запись/чтения одного файла. По-хорошему у нас должен появиться третий процесс, занимающийся этим в монопольном режиме с кэшированием. Но мы не будем делать по-хорошему, а попробуем положиться на средства ОС. Уточнение по задаче: процессы, взаимодействуя с внешним сервисом, получают информацию об актуальности некоторого статичного файла (грамматики, которую раздает nginx), в случае необходимости (если грамматика устарела) скачивают ее и сохраняют на диск. Как я уже сказал никакого менеджера очередей у нас не будет, процессы ничего не знают друг о друге, потому что, скажем, у нас дедлайны, а рулить доступ к ресурсам вообще может и должна ОС. Здесь мы замечаем flock(), имеется возможность создать назначать читателей вызовом flock(fd, LOCK_SH) и писателей flock(fd, LOCH_EX). Стандартное поведение нас практически устраивает, за исключением, что: если читаталей стало сильно много - писатели будут вставать в очередь, в большой конкуретности за это время будет накапливаться большая очередь из писателей, до того времени, пока не запишет хотя бы один, их очередь будет расти. Как только произойдет запись, уже не будет столь актуальным записывать еще тысячу раз одно и то же. Появляется искусственное ограничение - желание иметь в очереди записи всего 1 читателя, то есть блокировка должна выглядеть примерно так: flock(fd, LOCK_EX if LOCK_EX not in queue else LOCK_EX|LOCK_NB), что означает - если в очереди нет писателей, то встать в очередь записи с блокировкой, иначе попробовать захватить ресурс с LOCK_NB и получить отлуп по ошибке недоступности ресурса. Проблема в том, что механизм синхронизации на блокировании файлов даже сейчас это всего-лишь зайчатки нормального менеджера управления очередями, буквально никакого управления из клиентского кода очередью нет совсем, нет даже возможности ограничить очередь до 1. Вместо читателей и писателей теперь будем использовать lock_file, который будем забирать с LOCK_EX|LOCK_NB, как только кто-то хочет записать файл - захватывает этот ресурс и спокойно пишет в файл $FILENAME.new, как только дописал, то переносим новый файл mv $FILENAME.new $FILENAME, в этом случае (полагаясь на атомарность переименования) мы получаем безопасное чтение, каждый из читателей, не дожидаясь писателей, смогут прочитать целый файл, исключая неполного чтения. После записи отпускаем блокировку - задача решена. Использовать переименование вместо записи в исходный файл мы должны, чтобы обезопасить себя от того, что какая-то мразь (которую мы не контролируем, такая как nginx) все-таки прочитает неполный файл. Никогда не используйте примитивы синхронизации файловой системы, это сложная вещь, которая может выстрелить и которую вы будете дебажить очень много времени. Вместо этого расшаривайте память, пишите менеджеры очередей и не полагайтесь, что кто-то вместо вас обеспечит потокобезопасность одним простым вызовом. И вообще думайте о скалабельности чуть раньше, чем появится требования запустить второй и тысячный инстанс.