2012-02-24 3 views
8

Я хочу некоторое уточнение относительно мьютекса и семафора.
Мой вопрос,Что на самом деле делают мьютекс и семафор?

  1. Что мьютекс на самом деле, когда поток пытается войти в область заблокированный мьютекс, а. он ждет, когда замок будет выпущен? или b. он переходит в режим сна до тех пор, пока блокировка не будет отпущена. В этом случае, как он просыпается снова, когда блокировка освобождается?
  2. Тот же вопрос, что и 1, но в этом случае это семафор.
  3. Можете ли вы дать мне код, касающийся занятости в pthread в C, а также случай, когда нить идет спать, а не ждать? сон означает, что он заблокирован или спать - это еще один вид оживленного ожидания?
  4. Я хочу знать некоторые программы, в которых рассматриваются такие ситуации, например, некоторые исходные коды c, в которых заняты ожидание, блокировка и т. Д.
+0

Это домашнее задание? –

+0

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

ответ

5

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

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

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

Чтобы по-настоящему достичь оживленного ожидания, вам нужна атомная переменная, но потоки POSIX не предоставляют такую ​​вещь, поэтому вы не можете действительно писать оживленное ожидание в pthreads. Самое близкое, что вы можете получить, это заблокировать мьютексы, прочитать флаг, разблокировать мьютекс, цикл, если флаг не был установлен. Это несколько раз блокирует и разблокирует мьютексы, но не дожидаясь готовности данных. В этой ситуации вместо этого вы должны использовать переменную условия.

Как правило, вы говорите, что нить спала, если она вызвала что-то вроде usleep, чтобы приостановить собственное выполнение в течение определенного периода времени. Это в отличие от блокировки, когда она ждет определенного сигнала, который будет предоставлен другим потоком.

+0

", тогда он вызовет ядро ​​ОС, чтобы разбудить один из ожидающих потоков." , то это означает, что потоки фактически укладываются в ожидании разблокировки мьютекса или семафора? они не хранятся в фоновом режиме в течение определенного времени? –

+2

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

+0

Вы можете выполнить ожидание с использованием pthreads, поэтому есть функции pthread_spin_ {init, destroy, lock, unlock, trylock}. – janneb

-1

Простыми словами Mutex предназначен для тех случаев, когда вы заинтересованы в 1 блокировке .... Семафор предназначен для нескольких замков. Я попробую отправить вам образцы. Я помню, у меня были некоторые задания, связанные с семафор и мьютекс в C .. Что касается концепции касается это что-то смешное здесь http://geekswithblogs.net/shahed/archive/2006/06/09/81268.aspx :)

Благодарности

+0

Семафор также может использоваться для одного замка. –

0

Это зависит от типа мьютекса (реализация его поддержки), некоторые из них заняты спиннинг с оттоком, другие просто спят объект потока ядра, который затем будет разбужен при обновлении мьютекса, а некоторые из них являются гибридом из двух (двигатель источника Valve использует гибридные). Его характеристики также зависят от того, когда и как часто приходится преодолевать барьеры ядра/пользовательского пространства, так как иногда это может быть более дорогостоящим, чем просто откручивание немного дольше (см. this, если вы хотите получить больше возможностей для спиннинга или сна).

Мьютексы, как правило, для записи по одному потоку за один раз (хотя они могут поддерживать рекурсивную запись в том же потоке).Семафоры, с другой стороны, позволяют только n тем, чтобы попробовать их приобрести (см. Эту статью MSDN, или this сравнительный отчет Intel).

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

+0

Привет, меня особенно интересует реализация потоков posix в linux C. Итак, с точки зрения posix, что на самом деле делают мьютекс и семафор? Например, если я пишу код на C, где некоторые общие данные блокируются с помощью mutex, когда другие потоки приходят к доступу, будет ли он ждать? или просто заблокировали выделение ресурсов? и что произойдет в случае семафора. если поток блокирует то, как ожидание цикла и ожидание выполняется в posix C? Являются ли переменными условия единственным способом? –

0
  1. Что мьютекс на самом деле, когда поток пытается войти в область заблокированный мьютекс, а. он ждет, когда замок будет выпущен? или b. он доходит до до тех пор, пока замок не будет отпущен. В этом случае, как он проснулся снова , когда замок отпущен?

Когда поток пытается получить блокировку мьютекса, он застрял и возвращается только если блокировка предоставляются в эту тему. Блокировка распознается ОС, поэтому ОС знает, что до тех пор, пока такая блокировка не будет доступна, чтобы дать поток, ему больше нечего делать. Поток припаркован внутри ОС. Только OS знает, что теперь у потока есть собственная собственность, которая снова засыпает. В одной системе ЦП, в этом самом случае, если какой-либо другой процесс включен, блокировка мьютекса будет возвращаться только тогда, когда поток имеет оба - доступ к ЦП и блокировка!

Примечание: когда вы делаете fwrite или select То же самое бывает. Поскольку ОС знает, что соответствующий IO займет время, поток становится бездействующим. Когда данные поступают, поток становится работоспособным.

  1. Тот же вопрос, как 1, но в данном случае это семафор. Можете ли вы дать мне код, касающийся занятости, ожидающего в pthread в C, а также случай , где поток идет спать, а не ждать? сон означает, что это заблокирован или спал - это еще один вид оживленного ожидания?

В обоих случаях нет оживленного ожидания. Если кто-то будет ждать, чтобы убить время, пока вы не закроете замок, вы на самом деле не смогли заблокировать! Рассмотрим это, допустим, мы имеем строго один процессорный корпус (и глупую ОС). Итак, что происходит, поток 1 пытается получить блокировку, так как блокировка лежит в потоке B, поэтому поток A начинает делать ожидание. Следовательно, CPU никогда не выпускается из потока A, а поток B никогда не получает возможности выполнять на CPU - в конце оба потока в бесполезной ситуации. Замки ничего не делают на объекте нити. Но замок процесс неизменно парковать резьбе

+0

Привет, ладно, тогда вы имеете в виду, если есть необходимость в прядении, я должен явно реализовать ожидание, т. Е. С некоторыми переменными или переменными состояния? Я имею в виду, что мьютекс и семафор не позволяют потокам ждать, верно? например, если семафор инициализирован с помощью 5, тогда, когда он равен 5, другие потоки будут просто запущены ОС до тех пор, пока семафор не будет уменьшен с 5, а затем потоки будут разбужены ОС, верно? –

+0

@Pbasak, когда поток получает доступ к мьютексу (или если выполняется условие семафора), поток теперь «runnable» - в системе может быть много запущенных потоков, что зависит от других аспектов планирования ОС. Приобретение Mutex само по себе не контролирует другие потоки в системе, но ваш номер теперь находится в активной очереди. –

0

ожидания, спящий, блокирование, все это означает то же самое:

  1. Нить делает системный вызов (получить мьютекс или семафор, выждать некоторое время, что угодно)

  2. OS принимает управление, запускает планировщик, отмечает поток как ожидающий ресурса, обновляет статус других потоков, а затем дает управление потоку, который готов к запуску. Если более одного потока готовы к запуску, один выбирается в соответствии с политикой планирования.

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

Пока поток ожидает ресурса, он не потребляет процессор. С его стороны нет опроса.

3

Пожалуйста, обратите внимание на: https://stackoverflow.com/a/24582076/3163691

Да, оба семафора и семафора синхронизируются объекты ядра, которые, когда поток пытается приобретают один из них, этот поток ставятся на sleep если этот объект уже принадлежит другой теме.

Как вы уже догадались, это спать является весьма важным фактором, поскольку она позволяет другим потокам сделать более полезную работу, чем просто «зацикливание/опрос».

спальный из этих нитей заканчивается, когда кто нить владеет объект релиз его.

[OS Планировщик не дает при выполнении любого ломтик в спящих темы].

Contrast это с замком & где спин-блокировки поток находится в «зацикливание/занят, ожидающего» государственной тратить драгоценное процессорное время не делает почти ничего . Поэтому в коде пользователя следует избегать шпильки. Используйте критический раздел , мьютекс или семафор вместо этого.

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

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

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

Надеюсь, что это поможет.

Смежные вопросы