Мьютекс и монитор разница

Обновлено: 10.01.2025

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

Я прочитал эту ссылку Семафор против Мониторов - какая разница? который говорит, что монитор помогает в достижении взаимного исключения.

Может кто-нибудь сказать мне разницу между мьютексом и монитором, так как оба на самом деле делают одно и то же

2 ответа

Поскольку вы не указали, о какой ОС или языке / библиотеке вы говорите, позвольте мне дать общий ответ.

Концептуально они одинаковы. Но обычно они реализованы немного по-другому

монитор

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

Mutex

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

Monitor отличается от Mutex, но его можно считать схожим в том смысле, что Monitor построен поверх Mutex. Для ясности смотрите изображение монитора на изображении внизу.

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

Другими словами, наряду с данными, которые реализуют блокировку, каждый объект Java логически связан с данными, которые реализуют набор ожидания. В то время как блокировки помогают потокам работать независимо с общими данными, не мешая друг другу, наборы ожидания помогают потокам взаимодействовать друг с другом для достижения общей цели, например, все ожидающие потоки будут перемещены в этот набор ожидания, и все будут уведомлены. как только блокировка снята. Этот набор ожиданий помогает в создании мониторов с помощью дополнительной блокировки (mutex).

Если вы хотите, вы можете увидеть мой ответ здесь, который может иметь или не иметь отношение к этому вопросу.

Вы можете найти другое соответствующее обсуждение здесь

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

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

В терминологии Java монитор - это блокировка мьютекса, которая неявно связана с объектом. Когда synchronized Ключевое слово применяется к классам или методам, вокруг кода создается неявная блокировка мьютекса, которая гарантирует, что только один поток может выполнить его. Это называется блокировкой монитора или просто монитора.

Таким образом, в Java монитор - это не конкретный объект, а для любого объекта доступна блокировка монитора, которая вызывается с помощью synchronized ключевое слово.

В synchronized Ключевое слово также может использоваться в блоке кода, и в этом случае объект для блокировки указывается явно. Здесь это становится немного странным, потому что вы можете использовать монитор одного объекта для блокировки доступа к другому объекту.

В учебниках по информатике вы можете встретить другой вид монитора, монитор Бринча-Хансена или Хоара, который представляет собой класс или модуль, который неявно является потокобезопасным (например, синхронизированный класс в Java) и который имеет несколько условий, в которых потоки могут ждать / сигнал включен. Это концепция более высокого уровня, чем монитор Java.

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

Привет! Изучая многопоточность на JavaRush, ты часто встречал понятия «мьютекс» и «монитор». Сможешь сейчас, без подглядывания ответить, чем они отличаются? :) Если смог — молодец! Если же нет (а чаще всего так и бывает) — неудивительно. Понятия «мьютекс» и «монитор» действительно связаны между собой. Более того, читая лекции и смотря видео по многопоточности на внешних ресурсах в Интернете, ты столкнешься с еще одним похожим понятием — «семафор». Его функционал тоже во многом схож с монитором и мьютексом. Поэтому разберемся с этими тремя терминами, рассмотрим несколько примеров и окончательно упорядочим в голове понимание того, чем же они друг от друга отличаются :)

Мьютекс

Мьютекс — это специальный объект для синхронизации потоков. Он «прикреплен» к каждому объекту в Java — это ты уже знаешь :) Неважно, пользуешься ли ты стандартными классами или создал собственные классы, скажем, Cat и Dog : у всех объектов всех классов есть мьютекс. Название «мьютекс» происходит от английского «MUTual EXclusion» — «взаимное исключение», и это отлично отражает его предназначение. Как мы и говорили в одной из прошлых лекций, задача мьютекса — обеспечить такой механизм, чтобы доступ к объекту в определенное время был только у одного потока. Популярной аналогией мьютекса в реальной жизни можно считать «пример с туалетом». Когда человек заходит в туалет, он закрывает изнутри дверь на замок. Туалет выполняет роль объекта, доступ к которому получают несколько потоков. Замок на двери туалета — роль мьютекса, а очередь из людей снаружи — роль потоков. Замок на двери — мьютекс туалета: он гарантирует, что внутри одновременно может находиться только один человек. Иными словами, только один поток в определенное время может работать с общими ресурсами. Попытки других потоков (людей) получить доступ к занятым ресурсам будут неудачными. У мьютекса есть несколько важных особенностей. Во-первых, возможны только два состояния — «свободен» и «занят». Это упрощает понимание принципа работы: можно провести параллели с булевыми переменными true/false или двоичной системой счисления 1/0. Во-вторых, состояниями нельзя управлять напрямую. В Java нет механизмов, которые позволили бы явно взять объект, получить его мьютекс и присвоить ему нужный статус. Иными словами, ты не можешь сделать что-то типа: Таким образом освободить мьютекс объекта нельзя. Прямой доступ к нему есть только у Java-машины. Программисты же работают с мьютексами с помощью средств языка.

Монитор

Монитор — это дополнительная «надстройка» над мьютексом. Фактически монитор — это «невидимый» для программиста кусок кода. Говоря о мьютексе ранее, мы приводили простой пример: В блоке кода, который помечен словом synchronized , происходит захват мьютекса нашего объекта obj . Хорошо, захват-то происходит, но как именно обеспечивается «защитный механизм»? Почему при виде слова synchronized остальные потоки не могут пройти внутрь блока? Защитный механизм создает именно монитор! Компилятор преобразует слово synchronized в несколько специальных кусков кода. Еще раз вернемся к нашему примеру с методом doSomething() и дополним его: Вот что будет происходить «под капотом» нашей программы после того, как компилятор преобразует этот код: Пример, конечно, ненастоящий. Здесь мы с помощью Java-подобного кода попытались отразить то, что происходит в этот момент внутри Java-машины. Однако этот псевдокод дает отличное понимание того, что на самом деле происходит с объектом и потоками внутри блока synchronized и как компилятор преобразует это слово в несколько «невидимых» для программиста команд. По сути, монитор в Java выражен с помощью слова synchronized . Весь код, который появился вместо слова synchronized в последнем примере, — это и есть монитор.

Семафор

int permits — начальное и максимальное значение счетчика. То есть то, сколько потоков одновременно могут иметь доступ к общему ресурсу;

boolean fair — для установления порядка, в котором потоки будут получать доступ. Если fair = true, доступ предоставляется ожидающим потокам в том порядке, в котором они его запрашивали. Если же он равен false, порядок будет определять планировщик потоков.

Классический пример использования семафоров — задача об обедающих философах.

Мы немного упростим ее условия, для лучшего понимания. Представь, что у нас есть 5 философов, которым нужно пообедать. При этом у нас есть один стол, и одновременно находиться за ним могут не более двух человек. Наша задача — накормить всех философов. Никто из них не должен остаться голодным, и при этом они не должны «заблокировать» друг друга при попытке сесть за стол (мы должны избежать deadlock). Вот как будет выглядеть наш класс философа: А вот код для запуска нашей программы: Мы создали семафор со счетчиком 2, чтобы соответствовать условию: одновременно есть могут только два философа. То есть, одновременно работать могут только два потока, ведь наш класс Philosopher унаследован от Thread ! Методы acquire() и release() класса Semaphore управляют его счетчиком разрешений. Метод acquire() запрашивает разрешение на доступ к ресурсу у семафора. Если счетчик > 0, разрешение предоставляется, а счетчик уменьшается на 1. Метод release() «освобождает» выданное ранее разрешение и возвращает его в счетчик (увеличивает счетчик разрешений семафора на 1). Что же у нас получится при запуске программы? Решена ли задача, не передерутся ли наши философы, ожидая своей очереди? :) Вот какой вывод в консоль мы получили: Сократ садится за стол Платон садится за стол Сократ поел! Он выходит из-за стола Платон поел! Он выходит из-за стола Аристотель садится за стол Пифагор садится за стол Аристотель поел! Он выходит из-за стола Пифагор поел! Он выходит из-за стола Фалес садится за стол Фалес поел! Он выходит из-за стола У нас все получилось! И хотя Фалесу пришлось обедать в одиночку, думаю, он на нас не в обиде :) Ты мог заметить некоторое сходство между мьютексом и семафором. У них, в общем-то, одинаковое предназначение: синхронизировать доступ к какому-то ресурсу. Разница только в том, что мьютекс объекта может захватить одновременно только один поток, а в случае с семафором используется счетчик потоков, и доступ к ресурсу могут получить сразу несколько из них. И это не просто случайное сходство :) На самом деле мьютекс — это одноместный семафор. То есть, это семафор, счетчик которого изначально установлен в значении 1. Его еще называют «двоичным семафором», поскольку его счетчик может иметь только 2 значения — 1 («свободно») и 0 («занято»). Вот и все! Как видишь, все оказалось не таким уж и запутанным :) Теперь, если ты захочешь изучить тему многопоточности подробнее в Интернете, тебе будет чуть проще ориентироваться в понятиях. До встречи на следующих уроках!

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

Я прочитал эту ссылку Семафор против мониторов - какая разница? в котором говорится, что монитор помогает в достижении взаимного исключения.

Может ли кто-нибудь сказать мне разницу между мьютексом и монитором, поскольку оба они делают то же самое?

ОТВЕТЫ

Ответ 1

Поскольку вы не указали, какую ОС или язык/библиотеку вы говорите, позвольте мне ответить в общем виде.

Концептуально они одинаковы. Но обычно они реализованы несколько иначе

Monitor

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

мьютекса

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

Ответ 2

Мониторы отличаются от Mutex, но их можно считать похожими в том смысле, что Monitor строятся поверх Mutex. Для большей ясности смотрите изображение монитора в изображении внизу.

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

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

Я хочу, вы можете увидеть мой ответ здесь, который может или не может иметь отношение к этому вопросу.

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

Я прочитал эту ссылку Семафор и мониторы - в чем разница? который говорит, что монитор помогает в достижении взаимного исключения.

Может ли кто-нибудь сказать мне разницу между мьютексом и монитором, поскольку оба помогают достичь одного и того же (взаимное исключение)?

3 ответа

Поскольку вы не указали, о какой ОС или языке / библиотеке вы говорите, позвольте мне ответить в общем виде.

Концептуально они одинаковы. Но обычно они реализуются несколько иначе

Монитор

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

Мьютекс

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

Monitor отличается от Mutex, но их можно считать похожими в том смысле, что Monitor построен на основе Mutex. См. Изображение монитора на изображении внизу для ясности.

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

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

Если хотите, вы можете увидеть мой ответ здесь, который может иметь или не иметь отношения к этому вопросу.

Вы можете найти другое обсуждение здесь

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

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

В терминологии Java монитор - это блокировка мьютекса, которая неявно связана с объектом. Когда ключевое слово synchronized применяется к классам или методам, вокруг кода создается неявная блокировка мьютекса, которая гарантирует, что только один поток одновременно может его выполнить. Это называется блокировкой монитора или просто монитора.

Таким образом, в Java монитор - это не конкретный объект, скорее, любой объект имеет доступную блокировку монитора, которая вызывается с помощью ключевого слова synchronized .

Ключевое слово synchronized также может использоваться в блоке кода, и в этом случае объект для блокировки указывается явно. Здесь это становится немного странным, потому что вы можете использовать монитор одного объекта для блокировки доступа к другому объекту.

Читайте также: