Совместная координация mmap с использованием блокировок fcntl?

Question

При использовании mmap() для совместно используемой памяти (из Linux или других UNIX-подобных систем) возможно (и переносимо) использование fcntl() (или flock() или lockf() функций) для координации доступа на карту?

Ответы на этот вопрос SO , кажется, предполагает, что он должен работать.

Идея, которую я имею в виду, состоит в том, чтобы структурировать разделяемую память с картой процесса / страницы, чтобы минимизировать конфликт блокировки. Каждый процесс может работать со своими страницами одновременно, и блокировка должна быть получена только при обновлении отображений процесса / страницы. (Доступ для чтения с неизвестных страниц может включать проверку серийного номера, копирование требуемых данных и проверку того, что серийный номер этого блока не изменился).

Концептуально каждый процесс, совместно использующий это сопоставление файлов, будет выполнять mmap(), находить в нем свободный блок, получать блокировку для области процесса / страницы, обновлять ее своим назначением, снимать блокировку и затем весело продолжать со своей Работа. Любой процесс может найти устаревшие отображения (используя kill() с нулем в качестве сигнала) и очистить отображение таблицы процесса / страницы.

(В общих чертах, я играю с механизмом обработки производителя / потребителя, использующим разделяемую память из Python поверх Linux; я хотел бы, чтобы решение было переносимым на BSD и на другие языки программирования - так долго в качестве поддержки mmap() и необходимых интерфейсов для fcntl(), flock() или lockf(). я также был бы заинтересован в псевдо-коде, показывающем, как можно измерить конфликт блокировки и обнаружить любые ошибки синхронизации. Я знаю, что многопоточность и многопроцессорная обработка с соответствующими им объектами Queue() - самый простой способ реализации модели обработки производитель / потребитель Python).

Answer 1

Я уверен, что замки обеспечат взаимное исключение, но я не знаю, дадут ли они вам барьер памяти. Похоже, что прыжок в ядро ​​(что будут делать fcntl, flock и lockf), вероятно, сделает что-то , что вынудит неупорядоченные операции чтения и записи памяти для фиксации, но я сомневаюсь, что у вас возникнут серьезные проблемы гарантия. Я думаю, что это одна из тех вещей, где она, вероятно, работает, и тестирование покажет, что она работает, но вы не узнаете, что она всегда работает, если не найдете справку, говорящую так много.

Я сделал что-то похожее на C, но я использовал атомные спин-блокировки в самой общей памяти. Раньше вам приходилось делать небольшую встроенную сборку, но теперь у gcc есть некоторые внутренние операции, которые вы можете использовать:

http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html

Если вы хотите написать очень простое расширение Python, вы можете заключить __sync_lock_test_and_set (...) и __sync_lock_release (...), чтобы сделать то, что вам нужно. Они должны быть довольно портативными.

Я полагаю, что есть способ поместить мьютексы pthread в общую память, но у меня нет никакого опыта с этим. Опять же, вам нужно написать простое расширение C, чтобы получить доступ к нему из Python.