Очередь задач на обычном файле, когда база лишняя

Есть маленький прогон: список заданий на несколько тысяч строк, четыре рабочих процесса на одной машине. Заводить под такое базу рука не поднимается, хочется обойтись файлами.

Наивный вариант ломается сразу. Читать первую строку и вычёркивать её через sed -i четыре процесса одновременно не умеют: файл переписывается целиком, и половина заданий испаряется вместе с чужой правкой.

Как люди делают очередь на файлах, чтобы без потерь и без базы?

Файл тут не нужен вовсе, нужен каталог. Одно задание это один файл, а состояние задания это имя каталога, в котором файл лежит.

ochered/
  novye/     zadacha-0417.json
  v-rabote/
  gotovo/
  bityye/

Рабочий забирает задание переименованием из novye в v-rabote. Переименование внутри одной файловой системы атомарно: либо получилось, либо файла там уже нет. Два процесса за один файл не подерутся, проигравший получит ошибку и спокойно возьмёт следующий.

а как рабочий выбирает, какой файл брать? если все четверо пойдут за первым по алфавиту, трое получат ошибку

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

Драка снимается перемешиванием. Рабочий читает список, тасует его и идёт в своём порядке, тогда вероятность столкнуться падает до мелочи.

vzyat_zadachu() {
  for f in $(ls ochered/novye | shuf); do
    if mv "ochered/novye/$f" "ochered/v-rabote/$f.$$" 2>/dev/null; then
      printf '%s\n' "ochered/v-rabote/$f.$$"
      return 0
    fi
  done
  return 1
}

Номер процесса в имени пригодится дальше. Рабочий умер, его файлы остались в v-rabote, и уборщик по расписанию возвращает в novye всё, что старше получаса и чей процесс уже мёртв.

Второй приём для тех, кому четыре каталога кажутся грубыми: журнал с дописыванием. Файл только растёт, каждая строка это событие, взято или сделано. Состояние очереди собирается прочтением журнала с начала. Короткая строка под O_APPEND дописывается атомарно, поэтому четыре процесса пишут в один файл спокойно. Минус тоже понятный: журнал надо периодически сворачивать, иначе он пухнет без конца.

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

Одно уточнение к переименованию. Атомарность работает внутри одной файловой системы. Если novye и v-rabote оказались на разных точках монтирования, mv превращается в копирование с удалением, и вся гарантия испаряется.

Сетевые файловые системы туда же: на NFS поведение зависит от версии и настроек, я бы не рисковал.

Про монтирование верно. Проверяется одной строкой: stat -c '%d' ochered/novye ochered/v-rabote, номер устройства должен совпасть.

Сделал на каталогах. Четыре подкаталога, взятие через mv с перемешиванием списка, номер процесса в имени, уборщик раз в десять минут возвращает зависшие.

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

База под это правда лишняя, спасибо всем.