В поисках лучшего механизма блокировки файлов Boost для писателей — читателей
У меня есть файлы, расположенные в разных каталогах следующим образом:
\201603\30
file_1
file_2
\201603\31
file_3
file_4
file_5
Есть 2 писателя & 2 читателя, и они все темы в моей программе.
Блокировка будет применена к каталогу, а не к отдельным файлам (например, \ 201603 \ 30 или \ 201603 \ 31).
Я хотел бы использовать библиотеку boost, чтобы сделать мою программу переносимой.
Я искал и был представлен boost::interprocess::file_lock, Мне просто интересно, нужна ли мне здесь «межпроцессная» блокировка, и может ли эта блокировка делиться между читателями? Есть ли у вас какие-либо предложения, кроме boost::interprocess::file_lock?
Решение
Поскольку все блокирующие пользователи находятся в вашей программе, для чего вам нужна межпроцессная блокировка? file_lock помещает мьютекс в файл, который позволяет ядру управлять блокировкой / разблокировкой. Это полезно, только если несколько процессов должны соблюдать блокировку.
Похоже, вам не нужно ничего, кроме обычной блокировки чтения-записи, которую вызывает Boost shared_lock. Посмотрите этот ответ для примера того, как его использовать: https://stackoverflow.com/a/989816/321772
Таким образом, общая блокировка позволяет нескольким потокам получить блокировку для чтения, но позволяет только одному потоку обновить блокировку до записывающего устройства (исключая всех других читателей / записывающих устройств).
Другие решения
Как упоминал другой респондент, поскольку только один процесс использует файлы, которые вам не нужно блокировать в файловой системе, std :: shared_mutex или даже простой старый std :: mutex должно быть достаточно.
Однако, если вам нужно было эффективно заблокировать несколько процессов, а сейчас 2017 или более поздняя версия, вы можете рассмотреть возможность использования одного из алгоритмов shared_fs_mutex в переписывании после проверки предлагаемого Boost.AFIO v2: https://ned14.github.io/boost.afio/namespaceboost_1_1afio_1_1v2_1_1algorithm_1_1shared__fs__mutex.html. Причина, по которой я настаиваю на том, чтобы быть в 2017 году, заключается в том, что у AFIO v2 еще нет даже набора тестов, это в высшей степени альфа-код, и я пока не могу рекомендовать его использовать.