Условная переменная против семафора

Когда следует использовать семафор, а когда - условную переменную (CondVar)?

Замки используются для взаимного исключения. Если вы хотите, чтобы фрагмент кода был атомарным, поставьте вокруг него блокировку. Теоретически для этого можно использовать двоичный семафор, но это особый случай.

Семафоры и условные переменные строятся на основе взаимного исключения, обеспечиваемого блокировками, и используются для обеспечения синхронизированного доступа к общим ресурсам. Их можно использовать для аналогичных целей.

Переменная условия обычно используется, чтобы избежать ожидания занятости (многократного цикла при проверке условия) при ожидании доступности ресурса. Например, если у вас есть поток (или несколько потоков), который не может продолжать работу до тех пор, пока очередь не станет пустой, подход к занятому ожиданию будет заключаться в том, чтобы просто сделать что-то вроде:

//pseudocode
while(!queue.empty())
{
   sleep(1);
}

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

//pseudocode
syncVar.lock.acquire();

while(!queue.empty())
{
   syncVar.wait();
}

//do stuff with queue

syncVar.lock.release();

Предположительно, у вас будет нить где-то еще, которая вытаскивает вещи из очереди. Когда очередь пуста, она может вызвать syncVar.signal()пробуждение случайного потока, который спит syncVar.wait()(или обычно есть метод signalAll()or broadcast()для пробуждения всех ожидающих потоков).

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

Аналогичным образом можно использовать семафоры, но я думаю, что их лучше использовать, когда у вас есть общий ресурс, который может быть доступен или недоступен на основе некоторого целого числа доступных вещей. Семафоры хороши для ситуаций производитель / потребитель, когда производители распределяют ресурсы, а потребители их потребляют.

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

Каждый поток покупателя (потребителя), который приходит к автомату с газировкой, вызывает down()метод семафора, чтобы взять газировку. Это приведет к получению содовой из машины и уменьшению количества доступных газированных напитков на 1. Если есть доступные газированные напитки, код просто продолжит down()без проблем проходить мимо оператора. Если газированные напитки недоступны, поток будет спать здесь, ожидая уведомления о том, когда газированные напитки снова станут доступны (когда в машине будет больше газированных напитков).

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

Эти wait()и signal()методы переменной синхронизации , как правило , должны быть скрыты внутри down()и up()операций семафора.

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

Это не обязательно самое техническое описание, но оно имеет смысл в моей голове.

Давайте раскроем, что под капотом.

Условная переменная - это, по сути, очередь ожидания , которая поддерживает операции блокировки-ожидания и пробуждения, то есть вы можете поместить поток в очередь ожидания и установить его состояние на BLOCK, а также получить поток из него и установить его состояние на READY.

Обратите внимание, что для использования условной переменной необходимы еще два элемента:

• условие (обычно реализуется путем проверки флага или счетчика)
• мьютекс, который защищает условие

Затем протокол становится,

1. приобрести мьютекс
2. проверить состояние
3. заблокировать и освободить мьютекс, если условие истинно, иначе освободить мьютекс

Семафор - это, по сути, счетчик + мьютекс + очередь ожидания.И его можно использовать как есть без внешних зависимостей. Вы можете использовать его как мьютекс или как условную переменную.

Следовательно, семафор можно рассматривать как более сложную структуру, чем условную переменную, в то время как последняя более легкая и гибкая.

Семафоры можно использовать для реализации монопольного доступа к переменным, однако они предназначены для синхронизации. Мьютексы, с другой стороны, имеют семантику, которая строго связана с взаимным исключением: только процесс, заблокировавший ресурс, может разблокировать его.

К сожалению, вы не можете реализовать синхронизацию с мьютексами, поэтому у нас есть условные переменные. Также обратите внимание, что с помощью переменных условия вы можете разблокировать все ожидающие потоки в один и тот же момент, используя разблокировку широковещательной рассылки. Этого нельзя сделать с семафорами.

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

Барьерная синхронизация - это когда вы хотите, чтобы все ваши потоки ожидали, пока все не достигнут определенной части функции потока. это может быть реализовано с помощью статической переменной, которая изначально представляет собой значение общего числа потоков, уменьшенное каждым потоком, когда он достигает этого барьера. это будет означать, что мы хотим, чтобы каждый поток засыпал, пока не прибудет последний. Семафор будет делать прямо противоположное! с семафором каждый поток будет продолжать работать, а последний поток (который установит значение семафора на 0) перейдет в спящий режим.

переменная состояния, с другой стороны, идеальна. когда каждый поток достигает барьера, мы проверяем, равен ли наш статический счетчик нулю. если нет, мы переводим поток в спящий режим с помощью функции ожидания переменной условия. когда последний поток достигает барьера, значение счетчика будет уменьшено до нуля, и этот последний поток вызовет функцию сигнала переменной условия, которая разбудит все другие потоки!

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

Я склоняюсь к кодированию в сторону формы монитора; в большинстве языков, с которыми я работаю, все сводится к мьютексам, условным переменным и некоторым поддерживающим переменным состояния. Но семафоры тоже подойдут.

Операторы mutexи conditional variablesунаследованы от semaphore.

• Для mutex, в semaphoreиспользовании двух состояний: 0, 1
• Для получения condition variablesв semaphore счетчике использует.

Они похожи на синтаксический сахар