Что именно делает "блокировка мьютекса"?

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

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

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

теперь о том, как реализованы мьютексы. Мьютекс обычно реализуется с общей памятью. Существует некоторый общий непрозрачный объект данных, называемый мьютексом, и mutex_lock и mutex_unlock функции оба берут указатель на один из них. The mutex_lock функция проверяет и изменяет данные внутри мьютекса с помощью атомарного теста и набора или load-linked / store-условная последовательность команд (на x86,xhcg часто используется), и либо "приобретает мьютекс" - задает содержимое объекта mutex, чтобы указать другим потокам, что критическая секция заблокирована или подождать. В конце концов, поток получает мьютекс, выполняет работу внутри критического раздела и вызывает mutex_unlock. Эта функция устанавливает данные внутри мьютекса, чтобы отметить его как доступный, и, возможно, пробуждает спящие потоки, которые пытались получить мьютекс (это зависит от реализации мьютекса-некоторые реализации mutex_lock просто вращайтесь в плотном взгляде на xchg пока мьютекс не будет доступен, поэтому нет необходимости в mutex_unlock уведомить кого-либо).

Почему блокировка мьютекса будет быстрее, чем выход в память? Короче говоря, кэширование. CPU имеет кэш, к которому можно получить доступ очень быстро, поэтому xchg операция не должна идти до конца в память, пока процессор может гарантировать, что нет другого процессора доступ к этим данным. Но x86 имеет понятие "владения" линией кэша - если процессор 0 владеет линией кэша, любой другой процессор, который хочет использовать данные в этой строке кэша, должен пройти через процессор 0. Таким образом, нет необходимости в xhcg операция для просмотра любых данных за пределами кэша, а доступ к кэшу имеет тенденцию быть очень быстрым, поэтому получение неоспоримого мьютекса быстрее, чем доступ к памяти.

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