Использование fseek / fwrite из нескольких процессов для записи в разные области файла?

недавно я наткнулся на немного не проверенного устаревшего кода для записи данных, распределенных по нескольким процессам (это часть параллельного вычисления на основе MPI) в один и тот же файл. Это действительно гарантированно работает?

это выглядит так:

  • все процессы открывают один и тот же файл для записи.

  • каждый процесс называет fseek искать в другом месте в файле. Эта позиция может быть в прошлом конец файла.

  • каждый процесс затем записывает блок данных в файл с fwrite. Места поиска и размеры блоков таковы, что они полностью записывают плитку a раздел файла - ни пробелов, ни перекрытий.

это гарантированно работать, или это не страшно? Нет блокировки для сериализации записей, и на самом деле они, вероятно, будут начинаться с точки синхронизации. С другой стороны, мы можем гарантируйте, что они пишут в разные позиции файлов, в отличие от других вопросов, у которых были проблемы с попыткой записи в "конец файла" из нескольких процессов.

мне приходит в голову, что процессы могут быть на разных машинах, которые монтируют файл через NFS, что, как я подозреваю, вероятно, отвечает на мой вопрос-но будет ли это работать, если файл локальный?

7
c file-io mpi posix process

1 ответов

Я считаю, что это будет обычно работать, но нет никакой гарантии, что я могу найти. Спецификации Posix для fwrite (3) отсылают к ISO C, и ни один стандарт не упоминает параллелизм.

поэтому я подозреваю, что он обычно будет работать, но fseek(3) и fwrite(3) буферизованы функциями ввода-вывода, поэтому успех будет зависеть от внутренних деталей реализации библиотеки. Так что, абсолютно нет гарантия но различные причины ожидать, что он будет работать.

теперь, если программа использует lseek(2) и write (2), тогда я считаю, что вы можете считать результаты гарантированными, но теперь она ограничена операционными системами Posix.

одно кажется ... странный... зачем программа MPI решите поделиться своими данными через NFS а не API сообщений? Это казалось бы медленнее, менее портативным, более склонным к неприятностям и, как правило, просто пустой тратой набора функций MPI. Он, конечно, больше не распределяется, учитывая зависимость от одного NFS сервер.

4