У меня есть Linux процесс, называемый его «ведомый», который сначала по архитектурным соображениям существует, который создает некоторую общую память POSIX (SHM) и семафор POSIX. Затем он порождает другой процесс, называющий его «основным». Оба процесса будут использовать эти ресурсы для координации процесса master , отправляющего данные запроса на slave , и slave , возвращающего данные на master в ответ. Ключевой функцией семафора является защита доступа к SHM.
Предполагается, что мы достигли состояния, когда ведомое устройство заблокировано, а главное - нет (семафор 0, ведомое устройство ожидает из-за в sem_wait):
- в произвольный момент времени мастер записывает данные запроса в SHM.
- мастер-вызовы
sem_post, сразу же активируется подчиненный (семафор остается 0) . - мастер-вызовы
sem_wait, блокировка из-за того, что семафор 0. - вновь активированный ведомый читает данные запроса из SHM, вычисляет результат, записывает результат в SHM.
- рабские звонки * 1 028 *, немедленно пробуждаемый мастер (семафор остается
0). - ведомые вызовы
sem_wait, блоки, потому что семафор * 0. - вновь пробужденный мастер считывает данные результата из SHM.
Примечание: семафор остается 0 после каждого sem_post, потому что другой процесс (заблокированный) немедленно активируется и уменьшает его. Я не думаю, что какой-либо процесс когда-либо видит его со значением 1, поскольку пробуждение является атомом c.
В этот момент ведомое устройство блокируется, а ведущее - нет, поэтому весь процесс может повторяться снова и снова, как диктует мастер.
Проблема, с которой я столкнулся, - это переход в исходное состояние. Поскольку ведомый отвечает за порождение мастера, ему нужен способ заблокировать до того, как мастер получит возможность записи в SHM. Но раб не может блокировать, пока не породит хозяина, так как тогда он не сможет его породить. Если он блокируется сразу же после порождения мастера, возникает гонка, в которой мастер может записывать в SHM до того, как ведомое устройство фактически блокирует, что приводит к тому, что мастер не может ожидать ответ ведомого, и, следовательно, считывает недопустимые данные из SHM. Маловероятно, но это действительное условие гонки.
Так что я ищу эффективный, но наиболее важный правильный (свободный от гонки) способ распутать это - по сути, мне нужно, чтобы мастер как-то подождал, пока подчиненный заблокирует, прежде чем приступаю к выполнению, но я не хочу прибегать к опросам или произвольным задержкам, если только мне это не нужно.
У этой проблемы есть имя? Это похоже на инверсию управления, но я не уверен, как с помощью мастера создать / инициализировать семафор тоже будет работать. Мне нужно привести оба процесса в правильный шаг блокировки.
Я рассмотрел третий процесс, который отвечает за создание семафора, затем порождает подчиненное устройство, ждет, пока он не блокируется, и затем порождает мастер. , но я чувствую, что это та же проблема, потому что как первый процесс может проверить заблокированный подчиненный процесс с помощью API семафора POSIX?