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

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

Ответы наэтот вопрос SO , по-видимому, предполагают, что он должен работать.

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

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

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

1 3
python mmap shared-memory

1 ответ:

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

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

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

Если вы хотите написать очень простое расширение Python, вы можете обернуть _ _ sync_lock _ test_и _ set(...) и__sync _ lock _ release(...) что делать тебе нужно. Они должны быть довольно портативными.

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

1