Ищу статьи по проблемам блокировки общей памяти

Question

Я проверяю некоторый код и чувствую подозрение на используемую технику.

В среде Linux есть два процесса, которые подключают несколько сегменты разделяемой памяти. Первый процесс периодически загружает новый набор файлов для совместного использования и записывает идентификатор общей памяти (shmid) в местоположение в «главном» сегменте разделяемой памяти. Второй процесс постоянно читает это "главное" местоположение и использует shmid для прикрепления другие общие сегменты.

На хосте с несколькими процессорами, мне кажется, это зависит от реализации относительно того, что происходит, если один процесс пытается прочитать память, в то время как это пишется другим. Но, возможно, блокировка шины на аппаратном уровне предотвращает искалеченные биты на проводе? Это не имеет значения, если процесс чтения получил очень скоро, чтобы быть измененным значением, это имело бы значение, только если чтение было повреждено к чему-то, что не было ни старой ценностью, ни новой ценностью. Это крайний случай: только 32 бита записываются и читаются.

Поиск в интернете ничего не привел к чему-то определенному в этом площадь.

Я сильно подозреваю, что это небезопасно или нормально, и что бы я на самом деле Например, некоторые ссылки на статьи, подробно описывающие проблемы.

Answer 1

Ответ - абсолютно безопасно выполнять чтение и запись одновременно.

Понятно, что механизм шм обеспечивает голые инструменты для пользователь. Весь контроль доступа должен быть взят забота программиста. Блокировка и синхронизация любезно предоставленный ядром, это означает, что пользователь меньше беспокоится о расе условия. Обратите внимание, что эта модель обеспечивает только симметричный способ обмен данными между процессами. Если Процесс желает уведомить другого обработать, что новые данные были вставлен в общую память, он будет должны использовать сигналы, очереди сообщений, трубы, розетки или другие типы IPC.

С Общая память в Linux статья.

В последней реализации Linux shm просто используются вызовы copy_to_user и copy_from_user, которые внутренне синхронизируются с шиной памяти.

Answer 2

Звучит так, как будто вам нужен замок Reader-Writer: http://en.wikipedia.org/wiki/Readers-writer_lock.

Answer 3

Если shmid имеет тип, отличный от volatile sig_atomic_t, то вы можете быть уверены, что отдельные потоки будут иметь проблемы даже на одном и том же процессоре. Если типом является volatile sig_atomic_t, то вы не можете быть уверены в этом, но вам все же может повезти, потому что многопоточность может выполнять больше чередования, чем сигналы.

Если shmid пересекает строки кэша (частично в одной строке кэша и частично в другой), то во время записи процессора записи вы наверняка найдете часть чтения нового процессора и часть старого значения.

Именно поэтому были изобретены такие инструкции, как «сравнить и поменять местами».