Интересный вопрос мне тут задали.

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

x1ca4064,

Я, в общем, согласен с обоими вашими утверждениями. Но…

1. Вопрос задавался именно с намёком, что какие-то гарантии по времени существуют. Но кто и когда такие гарантии давал совершенно не понятно.

2. В чём смысл такого вопроса с точки зрения разработки многопоточных программ? Ведь поток 2 не может знать висел ли он на ожидании мьютекса или нет.

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

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

А правильный ответ: мьютекс будет захвачен "мгновенно". Просто функция разблокировки мьютекса в данном случае не будет его разблокировать, а просто "передаст" на "содержание" второму потоку. Второй поток захватит мьютекс до того как начнёт работать. Об этом и писал x1ca4064 . А уж когда второму потоку будет выделен квант времени — это вопрос десятый.

То есть если первый поток вызовет функцию захвата мутекса сразу после его освобождения, то
он гарантированно никогда мутекс не получит и она 100% упадёт в ожидание второго потока?
Ню-ню...

Откуда же у вас такие выводы?

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

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

В условиях ЦПУ голодания и фонового приоритета - никогда. Отсюда вывод: в ОС, которая
работает так, как Вы описываете, группа потоков, использующих один мутекс, работает с
приоритетом наинизшего из них.

Вообще-то так и есть, если упрощённо. Это называется priority failures, если не ошибаюсь.

А в RTOS для борьбы с этим есть инверсия приоритетов.

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

Что-то кажется мне, что вы заблудились.

Ну допустим мьютекс захватывается низкоприоритетным потоком 2 не мгновенно, а после получения
кванта времени. Этот поток в условиях "ЦПУ голодания и фонового приоритета" может никогда это
мьютекс и не отпустить. И все высокоприоритетные потоки зависнут на этом мьютексе.

В таких условиях этот поток мутекс никогда и не получит. Я же сказал: недостаточно знать
правильные ответы на вопросы, надо уметь оценить их последствия.

Ох, ну и ну. Если мы находимся в таких условиях, то в большинстве случаев нагрузка на ЦПУ не
равномерна. У низкоприоритетного потока всегда есть шанс захватить мьютекс. Хоть мгновенно,
хоть не мгновенно. А после этого обрушить логику работы высокоприоритетных потоков.

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

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

Или использовать инверсию приоритетов.

Dimitry Sibiryakov,

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

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