Кроссплатформенная блокировка файлов в PHP

Занялся доработкой своего микрофреймворка на PHP и столкнулся со следующей задачей. Во фреймворке предусмотрен встроенный планировщик задач, который не должен допускать одновременного выполнения одной и той же задачи в нескольких параллельных потоках. Такое может произойти, если во время выполнения задачи произойдёт второй запрос к серверу (или запуск параллельного процесса через cron). Насколько надёжно использовать в этих целях flock(), насколько хорошо она поддерживается в разных ОС? Если есть более предпочтительный вариант блокировок, то какой?

Из особенностей использования flock() под Windows известно, что на Windows нельзя писать в тот же файл, на котором стоит блокировка. Если подводные камни на этом заканчиваются, то flock() для данной задачи вполне подходит. Но больше всего настораживает предупреждение из официальной документации:

Если верить написанному, то получается, что flock() под Windows (если она подразумевается под «некоторыми операционными системами») будет корректно работать, например, с PHP-FPM, но не сработает в случае, если используется Apache с модулем PHP и в одном процессе Apache будет работать два потока, получающих блокировку на один и тот же файл.

В дополнение к этому стоит упомянуть нестандартный способ реализации блокировок, который можно использовать в качестве резервного. Но стоит ли его использовать — это большой вопрос. Дело в том, что создание каталога является атомарной операцией, а значит этим можно воспользоваться и вместо установки блокировки на файл создавать каталог через mkdir() и проверять возвращаемое ей значение, а в качестве снятия блокировки удалять каталог. Плюс способа в том, что он абсолютно кроссплатформенный и гарантированно будет работать на любых ФС. Ложка дёгтя тут заключается в том, что если во время выполнения задачи планировщика скрипт завершится с ошибкой, то каталог не удалится и следующего запуска задачи не произойдёт до тех пор, пока каталог не будет удалён вручную. Можно пойти дальше: если каталог уже существует, то проверять, сколько прошло времени с момента его создания и удалять его, если это время превышает минимальный интервал между запусками задачи (задаётся в конф. файле фреймворка). Но в таком случае если по какой-то причине задача будет выполняться дольше времени, указанного в конф. файле, то следующий запущенный процесс удалит каталог и запустит второй экземпляр задачи параллельно. Вывод становится очевиден: mkdir() не может полностью заменить flock() и его использование в любом случае чревато либо race condition'ами, либо риском в один прекрасный день обнаружить, что задача планировщика уже несколько месяцев не запускалась.

В своё время сталкивался с тем, что под Windows flock не работал, поэтому стараюсь его не использовать. В IntB 3 реализовал то, о чём ты говоришь через базу данных: таблица заданий блокируется через LOCK TABLE, из неё выбирается нужная задача, ставится пометка, что она уже выполняется (в случае с IntB — меняется время next_run на будущее для многоразовых задач), потом таблица разблокируется.
По поводу того, что ты предлагаешь — без базы примерно так и реализуют, только вместо каталога используют пустой вспомогательный файл (обычно с расширением lock), так как создание файла — быстрее, чем каталога, но тоже атомарная операция. Точнее, наверное, потребуется два файла: один — на весь список заданий, второй — на каждое конкретное. Причём в lock-файл со списком заданий нужно писать pid заблокировавшего его процесса, чтобы остальные могли проверить, жив ли этот процесс (аналогично pid-файлам в Linux). А чтобы сделать запись pid атомарной, нужно сначала писать в отдельный файл, а потом его переименовывать. Но всё равно это только снижает вероятность гонок, но не устраняет их полностью для случая, когда происходит захват lock-файла от убитого процесса.
Но самое надёжное — вешать на обычный системный cron скрипт, который будет запускаться каждую минуту и следить, есть ли синхронные и асинхронные задачи твоего приложения, которые нужно выполнить. Единственное что, нужно следить за временем после выполнения каждой из задач, и если прошло 59 секунд, завершаться, даже если задачи ещё остаются. Недостаток только один: не будет работать на хостингах, где не дают доступа к cron (хотя сейчас среди платных таких уже и не осталось, наверное). В частности, так сделано в InstantCMS, Oxwall, Friendica и множестве других скриптов.

Через базу данных — однозначно самый переносимый вариант. Но мне нужно именно без базы данных.

Вот так делать нельзя ни в коем случае, это не исключает race conditions, только уже потому, что проверка наличия файла и его создание — это две разные операции, между которыми существует временной промежуток. Отсюда возможна ситуация, когда два параллельных потока проверяют наличие файла блокировки и, не найдя его, создают его (оба одновременно) и начинают оба выполнять задачу. Весь смысл способа с каталогом в том, что создавая его, ты тут же и проверяешь его наличие по возвращаемому mkdir() значению — это одна атомарная операция, и это исключает race condition.

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

Та же проблема: операций две — чтение pid из файла и проверка существования процесса, а значит между этими операциями может что-нибудь произойти… Параллельные алгоритмы — это всегда «минное поле».

Да, у меня так и сделано. Но на всякий случай нужно иметь резервный вариант без cron'а. В некоторых случаях он удобнее, а иногда и единственный возможный, но это всё же редкость.

Была идея получать значение max_execution_time и, если каталог уже существует и старше max_execution_time, то удалять его. Но в документации нас предупреждают:

Так что способ с каталогом, видимо, отбраковывается. Самое лучшее — это блокировки на уровне ФС. А нет ли в PHP поддержки какого-нибудь ещё механизма блокировок, помимо flock()?

Вообще, в php есть для fopen опция 'x', которая судя по документации, сводится к выполнению системного вызова open с флагами O_EXCL|O_CREAT. И тогда это тоже получается атомарная операция, которая возвращает либо ошибку, если файл уже есть, либо создаёт его и возвращает resource-дескриптор.
Кстати, если PHP запускается через командную строку (или тот же системный cron), то max_execution_time не учитывается.

Насчёт O_EXCL — спасибо, буду знать.

Даже если он переопределён через set_time_limit()?

Кстати, а вариант использовать SQLite для этих целей ты не рассматривал?

Мысль такая приходила. И да, это было бы кроссплатформенно. Но это оправданно, на мой взгляд, только если в проекте и так используется SQLite. Не хотелось бы делать зависимость от SQLite ради одного только планировщика.