Каково практическое использование семафоров?

Ответ 1

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

"реальный sw, как Office, у Firefox есть места, где они его используют?"

Да, "реальное программное обеспечение" много использует семафоры, это не просто теоретическое, например. Источник хрома, код обработки семафора Windows и тот же код, который используется Виртуальная коробка.

"Каковы практические применения семафоров" / "Каковы общие шаблоны использования для семафоров?"

Они более подходят для проблем синхронизации производителей и потребителей. Ситуации, в которых у вас есть число производителей и потребителей и > 1.

Фурматор ссылка типичного использования семафоров - хорошие.

Ответ 2

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

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

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

Ответ 3

Семафор может рассчитывать. Подсчет является принципиально небезопасным, это операция чтения-изменения-записи на процессоре и, следовательно, не атомарная. Доступны меньшие примитивы для безопасного подсчета, Interlocked.Increment() является атомарным. Но атомичность - довольно слабый примитив с потоками, во многих случаях вам также нужно блокировать код, когда счетчик имеет критическое значение.

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

Двоичные семафоры часто появляются в литературе о потоках. Стандартный ввод текстовой книги и тесно связан с одним голландером по имени Эдсгер Дейкстра. Пионер в области компьютерных наук, который впервые начал думать в 1960-х годах о том, что вы сделали бы, чтобы получить процессор для запуска нескольких программ. Его аннотации P и V имеют смысл только для голландского спикера, подобного мне. Parkeer и Vrij - это те термины, которые вы используете, когда пытаетесь поставить свой автомобиль где-то:) Это было задолго до того, как все начали думать о том, что существуют разные типы примитивов, таких как мьютекс и монитор. Примитивы, которые требуют только поддержки семафора, после получения двоичного семафора, вы делаете все остальное. Построение абстракций поверх базового объекта, способ составления композиции в программном обеспечении.

Некоторое время лапши, я нахожусь в рулоне, одна вещь, которая делает Семафор совершенно отличным от других примитивов, таких как Mutex и Monitor, и блокировка - это то, что она не имеет сходства нитей. Это довольно сложная задача, когда вы пишете код с резьбой, обычный контракт, который вы пытаетесь реализовать, состоит в том, что только один поток может одновременно обращаться к ресурсу. Все остальные объекты синхронизации .NET являются повторными, вы не можете застопориться, сделав блокировку более одного раза в одном потоке. Они очень дружелюбны и просто увеличивают счетчик, когда вы приобретаете замок. И пересчитайте снова, когда вы отпустите. И только откажитесь от блокировки, когда счет достигнет 0. Семафор не работает таким образом вообще, он рассчитывает, когда вы приобретаете независимо от того, какой поток приобрел его. В некоторых случаях это действительно имеет значение, например, пример обратного потока-потока, который я цитировал ранее.

На самом деле это полезно. Не совсем очень часто. Монитор - швейцарский армейский нож с резьбой, поэтому он получил свое собственное ключевое слово. Ключевое слово блокировки в С#, SyncLock в VB.NET

Ответ 4

Цитата Дуга Шмидта в http://www.cs.wustl.edu/~schmidt/win32-cv-1.html раздел 2.2:

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

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

Что касается шаблонов, то по http://www.freertos.org/Real-time-embedded-RTOS-Counting-Semaphores.html

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

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

• Управление ресурсами. В этом сценарии использования значение count указывает количество доступных ресурсов. Чтобы получить контроль над ресурсом, задача должна сначала получить семафор - декремент значения счетчика семафора. Когда значение счета достигает нуля, свободных ресурсов нет. Когда задача заканчивается ресурсом, он "возвращает" семафор назад - увеличивает значение счетчика семафора. В этом случае желательно, чтобы значение счета было равно максимальному значению счета при создании семафора.

Ответ 5

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

Теперь я сомневаюсь, что, например, пул потоков Java реализован с использованием голого ресурса, такого как семафор, но какая-либо конструкция синхронизации используется, теоретически эквивалентна. Вы можете получить полное объяснение для пулов потоков Java (и пулов фиксированных потоков) здесь: http://docs.oracle.com/javase/tutorial/essential/concurrency/pools.html

Ответ 6

Я использовал семафор в производственной настройке несколько раз. Запустите службу Windows, которая получит список задач для выполнения. Эти задачи могут выполняться параллельно. Поэтому мы сначала просто бросили их все в .net Threadpool и запустили их.

Через короткий период возникла проблема. Работа, выполненная параллельно, также использовала threadpool. Поэтому, если мы запустили слишком много задач в threadpool, они будут потреблять весь пул, а затем ждать, пока их поставленная в очередь задача получит слот в threadpool.

Непроходимое решение состояло в том, чтобы просто сохранить общий счетчик, где задачи будут увеличиваться и уменьшаться по мере их продолжения. Это работало некоторое время, но в конечном итоге служба перестала бы делать что-либо. Повторные условия гонки привели к тому, что счетчик показывал, что все разрешенные слоты в threadpool были приняты, хотя ничего не было.

В конце Семафор решил проблему.