Следствия из алгоритма планировщика: низкоприоритетный поток может работать даже если работает поток с высоким приоритетом

Это перевод Consequences of the scheduling algorithm: Low priority threads can run even when higher priority threads are running. Автор: Реймонд Чен.

То, что вы запустили поток с высоким приоритетом, ещё не означает, что потоки с низким приоритетом не будут работать.

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

g_fReady: Boolean;
g_iResult: Integer;

...

// поток с высоким приоритетом
procedure SetResult(iResult: Integer);
begin
  g_fReady := True;
  g_iResult := iResult;
end;

...

// поток с низким приоритетом
if g_fReady then
begin
  UseResult(g_iResult);
end;

Давайте пока закроем глаза на слона в комнате: когерентность кэша. Если бы у нас были гарантии, что поток с низким приоритетом не будет работать, пока активен поток с высоким приоритетом, то этот код выглядит нормально. Даже если поток с высоким приоритетом прерывается и устанавливает результат (вызовом SetResult) после того как поток с низким приоритетом проверил флаг, то всё, что может произойти - поток с низким приоритетом пропустит результат (это не новость, поскольку принцип относительности одновременных событий и так говорит нам, что это возможно).

Однако, в реальной жизни у нас даже нет гарантии, что поток с низким приоритетом не может прервать поток с высоким приоритетом.

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

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

Представьте случай многопроцессорной системы (с изобретением HyperThreading этот случай становится всё более и более популярен. Прим.пер.: это было в 2005-м; сегодня же многоядерные процессоры являются типичным явлением), где у вас есть два готовых к выполнению потока - один с высоким приоритетом, другой - с низким. Планировщик запустит поток с высоким приоритетом на одном из процессоров. Но у него всё ещё есть второй (простаивающий) процессор, поэтому поток с низким приоритетом будет назначен на этот второй процессор. Теперь у вас получилось, что поток с низким приоритетом выполняется одновременно с потоком с высоким приоритетом.

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

Мораль истории: приоритеты потоков - это не замена правильной синхронизации потоков.

В следующий раз - обратное заблуждение.

(прим.пер.: кроме того, даже если у вас один процессор и поток с высоким приоритетом всегда готов к выполнению, поток с низким приоритетом всё ещё может выполняться - планировщик потоков время от времени выдаёт по несколько квантов времени всем голодающим потокам; подробнее см. книгу Джеффри Рихтера)