Глава 9. Планировщик горутин on Go: Under the Hood

9.1 Задача планирования и модель GMP

Mon, 01 Jan 0001 00:00:00 +0000

9.1 Задача планирования и модель GMP

Достаточно написать go f() — и горутина начинает выполняться. За этой единственной строкой стоит самый сложный механизм рантайма Go: планировщик (шедулер). Он должен ответить на вопрос, который совсем не прост: каким образом десятки тысяч горутин могут поочерёдно использовать небольшое число ядер процессора, работая быстро и оставаясь при этом практически незаметными для пользователя. В этом разделе сначала формулируется задача, которую должен решить планировщик, описывается его общая структура и место среди других конкурентных рантаймов. Последующие разделы подробно рассматривают каждый компонент.

9.2 Планирование с кражей работы

Mon, 01 Jan 0001 00:00:00 +0000

9.2 Планирование с кражей работы

9.1 оставил нам вопрос: у каждого P есть собственная локальная очередь, а значит, работа неизбежно распределяется неравномерно. Одни P перегружены, другие простаивают. Как распределить нагрузку, не создавая центрального узкого места, — это основная трудность конкурентного планирования. Ответ Go — схема с тридцатилетней теоретической базой, воспроизводимая во всей отрасли: кража работы (work stealing).

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

9.3 Модель MPG и единицы конкурентного планирования

Mon, 01 Jan 0001 00:00:00 +0000

9.3 Модель MPG и единицы конкурентного планирования

Первый вопрос, на который должен ответить шедулер, — не «как планировать», а «что планировать». Go называет объект планирования горутиной и реализует её на тройке M, P и G. Прежде чем перейти к алгоритму планирования (начиная с 9.4), этот раздел разбирает три единицы планирования: что такое горутина в контексте истории информатики, как кодируется её контекст выполнения, почему само планирование должно происходить на специальном g0, через какие состояния проходит горутина за свою жизнь и как поток M, несущий её, приостанавливается и возобновляется. Когда эти понятия прояснятся, все последующие алгоритмы планирования сведутся к «перемещению G между этими единицами».

9.4 Цикл планирования

Mon, 01 Jan 0001 00:00:00 +0000

9.4 Цикл планирования

Предыдущие разделы подготовили материал: мы знаем, что такое G, M и P (9.3), и знаем, как M находит работу (9.2). Этот раздел запускает всё в движение — мы наблюдаем, как цикл планирования непрерывно выбирает горутины и выполняет их в рамках одного потока, и как он удерживает баланс между «позволить отдельной горутине чуть дольше занимать процессор» (пропускная способность и локальность) и «не позволить ни одной горутине оголодать» (справедливость).

9.5 Управление потоками

Mon, 01 Jan 0001 00:00:00 +0000

9.5 Управление потоками

9.1 заложил трёхуровневую структуру GMP: G — единица выполнения на уровне пользователя, P — разрешение на планирование и носитель локальных ресурсов, а M — «нога», одолженная у операционной системы. Предыдущие разделы сосредоточились преимущественно на G и P; этот раздел переключает внимание на M и отвечает на ряд вопросов, откладывавшихся до сих пор: что такое M на самом деле, откуда он берётся, почему GOMAXPROCS ограничивает количество P, тогда как число потоков нередко оказывается больше, почему единственный блокирующий системный вызов не тормозит остальные G, и какую цену платит рантайм, когда пользователь хочет закрепить горутину за конкретным потоком (LockOSThread).

9.6 Обработка сигналов

Mon, 01 Jan 0001 00:00:00 +0000

9.6 Обработка сигналов

Сигналы операционной системы асинхронны и низкоуровневы: сигнал может прервать любой поток в произвольный момент, а набор действий, допустимых в обработчике сигнала, крайне ограничен. Типичный же запрос разработчика на Go — подключить канал к SIGINT через signal.Notify и выполнить корректное завершение по его приходу. Задача рантайма — выстроить мост между этими двумя реальностями: преобразовать непредсказуемый асинхронный сигнал в событие, которое горутина сможет безопасно обработать. Каждое проектное решение на этом мосту диктуется одним жёстким ограничением: что допустимо делать внутри контекста обработчика сигнала. Понимая это ограничение, всю остальную механику данного раздела можно воспринимать как её следствия.

9.7 Кооперация и вытеснение

Mon, 01 Jan 0001 00:00:00 +0000

9.7 Кооперация и вытеснение

В 9.5 Цикл планирования остался открытый вопрос: если некоторая G выполняется слишком долго, как остальные G всё равно смогут получить время процессора? Ответ неизбежно апеллирует к паре понятий из теории планирования — кооперативному и вытесняющему. Кооперативное планирование опирается на добровольную уступку управления планируемой стороной; вытесняющее — на прерывание планируемой стороны планировщиком извне.

Рантайм Go не располагает возможностью аппаратного прерывания, подобной ядру операционной системы. Планировщик с перехватом работы (9.2) по своей сути является кооперативным планированием в порядке поступления. Вопрос в том, как он всё же способен принудительно прерывать G, отказывающуюся уступать управление, не отступая при этом от данного принципа — именно это и предстоит прояснить в настоящем разделе. Отправной точкой служит теоретический вопрос: почему рантайм не может остановить горутину в произвольной инструкции?

9.8 Системный монитор

Mon, 01 Jan 0001 00:00:00 +0000

9.8 Системный монитор

Штатный путь планировщика описан в 9.4 Цикл планирования: один M привязывается к одному P, извлекает горутину из очереди, выполняет её, затем берёт следующую. Этот путь опирается на одно условие — что M вообще получает возможность работать. Но стоит всем P застрять в длительных системных вызовах, или какой-либо горутине уйти в бесконечный цикл и намертво удерживать P, — обычное планирование встаёт. Никто не забирает P обратно, никто не опрашивает сеть. Иными словами, кооперативная логика, выполняемая на P, не способна справиться с ситуацией, когда «сам P не может двигаться».

9.9 Опросчик сети

Mon, 01 Jan 0001 00:00:00 +0000

9.9 Опросчик сети

Исходные факты верифицированы по src/runtime/netpoll.go и его платформенным реализациям (netpoll_epoll.go, netpoll_kqueue.go и другим), а также по src/internal/poll/fd_unix.go.

Сетевой код Go выглядит блокирующим: conn.Read просто «зависает» в ожидании данных. Но если бы он действительно блокировал поток операционной системы, на котором выполняется, то десять тысяч горутин, ожидающих данных из сети, удерживали бы десять тысяч потоков, и модель M:N, тщательно выстроенная в 9.1, мгновенно рухнула бы. Возможность сохранить блокирующий стиль и при этом обеспечить масштабируемость — заслуга опросчика сети (netpoller). За ним стоит долгая история «как обслуживать огромное число соединений с помощью горстки потоков». Этот раздел сначала излагает эту историю и определяющие оси проектирования, а затем рассматривает, как Go скрывает зрелый механизм событий внутри рантайма: программист пишет синхронный код, а под капотом работает событийно-ориентированный ввод-вывод.

9.10 Таймеры

Mon, 01 Jan 0001 00:00:00 +0000

9.10 Таймеры

time.Sleep, time.After, time.Timer, time.Ticker и даже SetDeadline для сетевого чтения и записи — всё это опирается на одну и ту же инфраструктуру таймеров. Она должна отвечать на вопрос, который выглядит простым, но на деле весьма тонок — вопрос о структурах данных: когда одновременно существуют тысячи таймеров, как эффективно определить «кого нужно разбудить следующим, и когда», не выжигая при этом отдельный поток? Этот раздел начинается с постановки абстрактной задачи, разбирает компромиссы различных решений и приходит к выбору Go и его эволюции.

9.11 NUMA-осведомлённость и будущее планировщика

Mon, 01 Jan 0001 00:00:00 +0000

9.11 NUMA-осведомлённость и будущее планировщика

Планировщик, описанный в предыдущих разделах, опирается на предположение, которое нигде явно не сформулировано: каждый M обращается к памяти с одинаковой скоростью, а стоимость перемещения G между любыми двумя P одинакова. На ноутбуке или однопроцессорном сервере это предположение почти верно. Но стоит запустить программу на крупном многопроцессорном сервере — оно начинает трещать, и чем больше ядер, тем шире трещина. Этот раздел посвящён именно ей: откуда она берётся, почему планировщик Go так долго её игнорировал, какой NUMA-осведомлённый дизайн был тщательно проработан, но так и не выпущен, и как пользователи обходят проблему сегодня.