Затраты на получение блокировки зависят от разрешения таймера ОС при переключении контекста?

Question

Предположим, что поток 1 пытается получить блокировку объекта lockObj, используя lock(lockObj) оператор, но этот объект уже заблокирован потоком 2 в тот момент, когда поток 1 пытается получить блокировку для него. Тема 1 заблокирует, верно?

Теперь предположим, что во время этой блокировки происходит переключение контекста, потому что есть другие потоки и приложения, ожидающие запуска. Прошло ли время, пока поток 1 снова не вошел в состояние " Выполнено" и смог установить блокировку, зависит от разрешения таймера ОС (например, 15,6 мс по умолчанию в Windows 7)?

Если ответ на поставленный выше вопрос - ДА, у меня есть еще одно сомнение:

Легко создать простую программу для проверки средней нагрузки Thread.Sleep(1) с помощью секундомера и заключаем, что он сходится к разрешению таймера ОС (например, 15,6 мс). Но мне трудно создать программу, чтобы получить такой же вывод для оператора блокировки. Главным образом потому что:

1) Трудно гарантировать, что поток, пытающийся получить блокировку, всегда будет блокироваться (или, по крайней мере, знать, КОГДА он заблокировал, прежде чем получить блокировку);

2) Я не знаю, как принудительно переключать контекст, когда поток пытается получить блокировку. Есть ли ВСЕГДА переключатель контекста, когда текущий запущенный поток блокируется?

Любая помощь будет оценена.

Answer 1

Предположим, что поток 1 пытается получить блокировку для объекта lockObj с помощью оператора lock(lockObj), но этот объект уже заблокирован потоком 2 в тот момент, когда поток 1 пытается получить блокировку для него. Тема 1 заблокирует, верно?

Да.

Теперь предположим, что во время этой блокировки происходит переключение контекста, потому что есть другие потоки и приложения, ожидающие запуска. Прошло ли время, пока поток 1 снова не вошел в состояние "Выполнено" и смог установить блокировку, зависит от разрешения таймера ОС (например, 15,6 мс по умолчанию в Windows 7)?

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

Если есть ядро, свободно запускающее поток 1, я обнаружил эмпирически, что оно работает ~7us после сигнала из потока 2 в моей системе Windows - несколько микросекунд, а не 15,6 мс или что-то подобное.

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

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