Отличия семафоров System V и Posix

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

15.12.2008 13:13:26
3 ОТВЕТА
РЕШЕНИЕ

От О'Рейли :

  • Одно заметное отличие между реализациями семафоров 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 обеспечивают механизм для непостоянных семафоров.
52
15.12.2008 13:36:44

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

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

10
11.10.2012 22:34:52
Извините, я не понял, что вы имеете в виду под "способностью получать ресурс семафора способом, который автоматически возвращается ядром. НЕТ, КАК ВЫХОДИТ ИЗ ПРОЦЕССА". Можете ли вы объяснить это немного больше?
Fingolfin 11.10.2012 22:58:26
@ xci13: семафор не освобождается автоматически, если процесс завершен (например, с помощью SIGKILL). Смотрите ответ iggie .
Craig McQueen 18.06.2015 07:11:53

Две основные проблемы с общими / именованными семафорами 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 непригодными для использования в реальной системе без гарантии того, что неуловимые сигналы никогда не будут отправлены. Ограничение два может быть смягчено тщательным кодированием, предполагая контроль над всем кодом, который будет использовать данный семафор. Честно говоря, более чем удивительно, что они сделали это стандартом, как они есть.

25
24.02.2013 07:41:50
Кроме того, сделать семафоры POSIX рекурсивными (как рекурсивная блокировка) нелегко, и у них есть странная особенность: когда кто-то разблокирует (sem_post ()) семафор более одного раза (например, по ошибке), затем последующая блокировка (sem_wait () ) оставлю это открытым. Другая обработка: 0 - разблокирована, любая другая, чем 0 - заблокирована (с настройкой максимального значения), решит обе вышеуказанные проблемы.
Radoslaw Garbacz 20.12.2018 15:55:32
Семафоры предназначены для сигнализации о ДРУГИХ процессах или потоках. Таким образом, они не используются для замков, и они не удерживаются. Если вам нужна семантика владения, вы должны использовать мьютекс, а не семафор (см. Pthread_mutex_t). В частности, если вы хотите получать уведомления о смерти другого процесса при удержании блокировки, вы должны пометить мьютекс как процесс, совместно используемый и устойчивый.
Mabus 26.01.2019 22:49:39