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

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

4 ответов


с О'Рейли:

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

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


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

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


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

в связанной статье обсуждается, что неправильно и не интуитивно понятно с семафорами System V.