Почему POSIX стандартизирует семафор как системный вызов, но оставляет мьютекс и переменную условия для Pthread (уровень пользователя) - PullRequest
1 голос
/ 03 марта 2020

Я задал этот странный вопрос, который преследовал меня. Почему POSIX стандартизирует поддержку семафора как syscall, но оставляет условную переменную и мьютекс библиотеке pthread?

Что такое разделение ответственности здесь? Почему семафор не стандартизирован в пакете Pthread? Почему системный вызов для синхронизации, который стандартизирует POSIX, является семафором, а не мьютексом, условной переменной?

Не знаю. Предположим, производительность заключается в том, чтобы не реализовывать мьютекс как системный вызов. (Аппаратные инструкции Atomi c непривилегированы, поэтому их реализация на уровне пользователя возможна. Несмотря на то, что Linux предоставляет futex, он на самом деле пытается оптимизировать спин-блокировку в двухфазную блокировку, в направлении блокировки сна). И причина семафора в том, что семафор может управляться другим процессом, по сравнению с тем фактом, что мьютекс может быть разблокирован только процессом, который его удерживает? Операция V семафора позволяет процессу ожидать его разблокирования. Таким образом, семафор хранится в ядре, а идентификатор семафора подобен файловому дескриптору, возможности, предоставляемой ядром, что делает его системным вызовом, а не чисто пользовательским пакетом.

А как насчет условной переменной? Есть ли причина указывать это в Pthread, но не на уровне системного вызова? Поскольку он не имеет состояния и происходит от монитора, который является чисто программной конструкцией без учета состояния, поэтому он может быть реализован с использованием мьютекса?

Спасибо!

1 Ответ

1 голос
/ 03 марта 2020

Краткий ответ: семафоры и pthreads имеют разные истории.

Да: семафоры могут использоваться между процессами, в которых содержимое pthreads (как правило) находится внутри текущего процесса, или между процессами, которые совместно используют память.

С точки зрения производительности: быстрый удар (на моем x86_64) говорит мне, что sem_wait() и sem_post() используют простые lock cmpxchg инструкции, делая syscall только для приостановки / пробуждения потока. По сути, это то же самое, что и pthread_mutex_t - когда семафор используется как мьютекс.

Очевидно, что семафор может делать то, что не делают мьютекс и переменная условия, и вы можете использовать безымянные семафоры внутри процесса - sem_init() с pshared=0.

Я думаю, разработчики pthread решили, что указание pthread_sema_t было бы ненужным дублированием. К сожалению, это оставляет место для сомнений, что (более общий) семафор может иметь проблемы с производительностью, даже если используется только внутри процесса :-( Или, действительно, есть некоторые сомнения, что семафор и pthread всегда хорошо сочетаются: - (

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...