Различия между семафорами System V и Posix

Каковы компромиссы между использованием семафоров System V и Posix?


semaphore unix comparison posix tradeoff
person corto    schedule 15.12.2008    source источник

Ответы (3)


arrow_upward
54
arrow_downward

Из O'Reilly< /а>:

  • Одно заметное различие между реализациями семафоров в System V и POSIX заключается в том, что в System V вы можете контролировать, насколько может увеличиваться или уменьшаться число семафоров; тогда как в POSIX количество семафоров увеличивается и уменьшается на 1.
  • Семафоры POSIX не позволяют манипулировать разрешениями семафоров, тогда как семафоры System V позволяют изменять разрешения семафоров на подмножество исходных разрешений.
  • Инициализация и создание семафоров атомарны (с точки зрения пользователя) в семафорах POSIX.
  • С точки зрения использования семафоры System V неуклюжи, а семафоры POSIX прямолинейны.
  • Масштабируемость семафоров POSIX (с использованием безымянных семафоров) намного выше, чем у семафоров System V. В сценарии пользователь/клиент, где каждый пользователь создает свои собственные экземпляры сервера, было бы лучше использовать семафоры POSIX.
  • Семафоры System V при создании объекта семафора создают массив семафоров, тогда как семафоры POSIX создают только один. Из-за этой функции создание семафора (с точки зрения объема памяти) обходится дороже в семафорах System V по сравнению с семафорами POSIX.
  • Было сказано, что производительность семафоров POSIX выше, чем у семафоров на основе System V.
  • Семафоры POSIX предоставляют механизм для семафоров всего процесса, а не семафоров всей системы. Итак, если разработчик забывает закрыть семафор, при выходе из процесса семафор очищается. Проще говоря, семафоры POSIX предоставляют механизм для непостоянных семафоров.
person ezkl    schedule 15.12.2008

arrow_upward
26
arrow_downward

Две основные проблемы с общими/именованными семафорами POSIX, используемыми в отдельных процессах (не потоках): семафоры POSIX не предоставляют механизма для пробуждения ожидающего процесса, когда другой процесс умирает, удерживая блокировку семафора. Это отсутствие очистки может привести к семафорам-зомби, что приведет к тупику любого другого или последующего процесса, который попытается их использовать. Также нет способа POSIX перечислить семафоры в ОС, чтобы попытаться идентифицировать и очистить их. В разделе POSIX в SysV IPC указаны инструменты ipcs и ipcrm для вывода списка глобальных ресурсов SysV IPC и управления ими. Для POSIX IPC такие инструменты или даже механизмы не указаны, хотя в Linux эти ресурсы часто можно найти в /shm. Это означает, что сигнал KILL неправильному процессу в неподходящее время может заблокировать всю систему взаимодействующих процессов до перезагрузки.

Другим недостатком является использование файловой семантики для семафоров POSIX. Подразумевается, что может быть более одного общего семафора с одним и тем же именем, но в разных состояниях. Например, процесс вызывает sem_open, затем sem_unlink перед sem_close. Этот процесс по-прежнему может использовать семафор так же, как удаление открытого файла перед его закрытием. Процесс 2 вызывает sem_open на том же семафоре между вызовами sem_unlink и sem_close процесса 1 и (согласно документации) получает совершенно новый семафор с тем же именем, но в другом состоянии, чем процесс 1. Два общих семафора с одинаковыми именами независимое функционирование сводит на нет цель общих семафоров.

Ограничение, приведенное выше, делает общие семафоры POSIX непригодными для использования в реальной системе без гарантии того, что неперехватываемые сигналы никогда не будут отправлены. Ограничение два можно смягчить тщательным кодированием, принимая на себя контроль над всем кодом, который будет использовать данный семафор. Честно говоря, более чем удивительно, что они вошли в стандарт такими, какие они есть.

person iggie    schedule 24.02.2013
comment
Кроме того, нелегко сделать семафоры POSIX рекурсивными (как рекурсивная блокировка), и у них есть странная особенность, когда кто-то разблокирует (sem_post()) семафор более одного раза (например, по ошибке), последующая блокировка (sem_wait() ) оставит его открытым. Другая обработка: 0 - разблокирована, любая другая, кроме 0 - заблокирована (с настройкой максимального значения), решит обе вышеуказанные проблемы. - person Radoslaw Garbacz; 20.12.2018
comment
Семафоры предназначены для сигнализации ДРУГИМ процессам или потокам. Таким образом, они НЕ используются для замков и не являются удержанием. Если вам нужна семантика владения, вы должны использовать мьютекс, а не семафор (см. pthread_mutex_t). В частности, если вы хотите получать уведомления о смерти другого процесса во время удержания блокировки, вы должны пометить мьютекс как общий и надежный процесс. - person Mabus; 27.01.2019

arrow_upward
10
arrow_downward

Я знаю, что это старо, но для тех, кто все еще читает это любезно предоставленное Google, причина № 1, по которой я нахожу использование семафоров System V вместо семафоров POSIX (системного уровня), — это возможность получить ресурс семафора таким образом, который автоматически возвращается ядром, НЕЗАВИСИМО ОТ КАК ПРОЦЕСС ВЫХОДИТ.

Я согласен с тем, что множественные (атомарные) операции с семафорами редко используются (хотя они могут быть полезны во время постановки) и что интерфейс System V странен, но просто нет способа надежно добиться такой же семантики очистки с семафорами POSIX.

person Peter    schedule 11.10.2012
comment
Извините, я не понял, что вы имеете в виду под способностью получать ресурс семафора таким образом, который автоматически возвращается ядром, НЕЗАВИСИМО ОТ КАК ПРОЦЕСС ВЫХОДИТ. Не могли бы вы объяснить это немного подробнее? - person Fingolfin; 12.10.2012
comment
@ xci13: семафор не освобождается автоматически, если процесс убит (например, с помощью SIGKILL). См. ответ Игги. - person Craig McQueen; 18.06.2015