2017-02-05 11 views
0

Согласно моим знаниям, процесс блокировки мьютекса - это тот, который должен разблокировать мьютексы. Мое сомнение заключается в том, что процессор знает, какой процесс разблокировать? Есть ли какая-либо структура данных, которая сохраняет pid (или) что-то из этого конкретный процесс (внутренне) в waitque? так что процессор может только разблокировать конкретный процесс.В мьютексе, как процессор (ЦП) знает, какой процесс разблокировать?

, пожалуйста, ответьте. Этот вопрос задан в одном из моих интервью.

+0

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

ответ

0

Нить/процесс, который получил мьютекс, является единственным, который движется вперед в коде. Позже в коде для этого потока должна быть выпущена мьютекс. Другие потоки/процессы, которые не имеют мьютекса, будут ждать его, чтобы они не приняли его или не отпустили, пока 1 работающий процесс не попадет в релиз мьютекса.

0

как процессор знает, какой процесс разблокировать?

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

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

Итак, возникает вопрос: как программное обеспечение ОС знает, какой поток просыпаться после разблокировки мьютекса?

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

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

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

+0

thanku для ур ответ ... я понял, что сказал .. что вы на самом деле имеете в виду, когда упоминаете «переустанавливает право собственности на мьютекс на этот поток»? @Jeremy Friesner – sravanthi

+0

@sravanthi только одна нить удерживает мьютекс за раз; поток, который содержит мьютекс, считается владельцем мьютекса. Когда функция lock() вернулась в поток, гарантируется, что этот поток является владельцем мьютекса.Поэтому, если поток B ждет внутри lock(), потому что поток A является владельцем мьютекса, а поток A вызывает unlock() на мьютексе, в этот момент поток B станет владельцем мьютекса и блокировки B потока() вызов вернется, так что поток B может возобновить выполнение. –

+0

благодарю столько за ур ответ ... @ Джереми Фризнер – sravanthi