Как на самом деле устроен Планировщик в Go? Детальный разбор простым языком

• В Go нет механизмов работы с конкурентным кодом.  

• Современные компьютеры имеют многоядерные процессоры, что позволяет выполнять задачи параллельно.  

• Конкурентность позволяет выполнять задачи быстрее, распределяя их по ядрам процессора.  

• Планировщик управляет выполнением задач.  

• Планировщик - это набор механизмов, а не отдельная сущность.  

• Изучение планировщика полезно для понимания работы с конкурентным кодом в Go.  

• Планировщик помогает оптимизировать работу с файлами и сетевыми запросами.  

• Важно понимать, сколько воркеров можно использовать для выполнения задач.  

• В разных случаях количество воркеров может варьироваться.  

• Поверхностное понимание может быть забыто, а глубокое - нет.  

• Понимание механизмов работы планировщика помогает оптимизировать код.  

• Это помогает в развитии и работе.  

• Планировщик должен задействовать все ядра процессора.  

• Конкурентная работа должна быть дешевой и простой.  

• Простота выполнения задач асинхронно с помощью ключевого слова go.  

• Задачи выполняются параллельно только при наличии нескольких ядер.  

• Процессор быстро переключается между задачами, создавая иллюзию одновременного выполнения.  

• Одновременность - понятие относительное, зависящее от восприятия человека.  

• Конкурентность относится к дизайну кода, а параллельность — к его выполнению.  

• Конкурентное выполнение позволяет планировщику выполнять функции в любой последовательности.  

• Параллельное выполнение означает выполнение двух функций одновременно.  

• Ядро процессора имеет один слот для выполнения задачи.  

• Планировщик операционной системы управляет тредами, которые могут находиться в трех состояниях: выполнение, ожидание и завершение.  

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

• Треды требуют много памяти и частое переключение контекста делает их дорогими.  

• Чем больше тредов, тем чаще происходит переключение контекста, что может быть соразмерно времени выполнения полезной работы.  

• Минимизация количества тредов и переключение контекста — важная задача.  

• Планировщик Go управляет горутинами, которые живут в пользовательском пространстве.  

• Горутины выполняются на тредах, что позволяет оптимизировать их работу.  

• Планировщик Go использует треды для выполнения горутин, что позволяет избежать фундаментальных ограничений операционной системы.  

• Горутины имеют три состояния: выполнение, ожидание и завершение.  

• Планировщик Go аналогичен планировщику операционной системы, но использует горутины вместо тредов.  

• Процессор помещает горутины на треды и управляет их выполнением.  

• Для каждой горутины создается отдельный тред.  

• Это обеспечивает конкурентность и параллельность, задействуя все ядра процессора.  

• Модель один к одному подходит для реализации конкурентной работы.  

• Создание и уничтожение тредов дорого и тормозит конкурентность.  

• Идея: не уничтожать треды, а откладывать их в пул тредов.  

• При появлении новой грудины использовать свободный тред из пула.  

• Существование тредов также дорого из-за памяти и переключения контекста.  

• Решение: ограничить количество тредов.  

• Если лимит исчерпан, грудине придется ждать, пока освободится тред.  

• Грудины, которым не хватило треда, попадают в очередь.  

• Очередь называется "глобал ран кью" или "джерк".  

• Используются концепции FIFO и LIFO.  

• В ролике не рассматриваются сложные оптимизации.  

• Дополнительные материалы доступны на бусти, патрионе и закрытом телеграм-канале.  

• Поддержка автора важна для создания контента.  

• Вопрос: каким количеством тредов ограничивать пул?  

• Пример с тремя ядрами: два треда занимают два ядра.  

• Решение: лимит тредов должен соответствовать количеству ядер процессора.  

• Проблема: общий доступ к ресурсу между несколькими процессорами.  

• Решение: каждый процессор имеет свой пул тредов.  

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

• Для решения этой проблемы используется мьютекс, который блокирует ресурс, пока один процессор не завершит работу.  

• Это позволяет избежать конфликтов и обеспечивает предсказуемое выполнение задач.  

• Модель MCN предполагает, что на каждом процессоре выполняется одна задача.  

• Это решает проблему конфликтов, но замедляет работу программы при большом количестве процессоров.  

• Для устранения этой проблемы предлагается использовать локальные очереди для каждого процессора.  

• Каждый процессор получает свою локальную очередь, что устраняет необходимость в блокировках.  

• Процессоры могут брать задачи из своих очередей без задержек.  

• Глобальная очередь остается полезной для задач, которые не привязаны к конкретному процессору.  

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

• Это приводит к простаиванию задач в глобальной очереди.  

• Для решения этой проблемы процессоры должны иногда заглядывать в глобальную очередь.  

• Процессоры должны заглядывать в глобальную очередь каждые 61 цикл.  

• Это число было выбрано экспериментально для минимизации коллизий и простаивания задач.  

• Принцип работы аналогичен хэш-таблицам, что можно понять из предыдущего ролика.  

• Каждый процессор проверяет глобальную очередь каждые 61 цикл.  

• Если в глобальной очереди ничего нет, проверяется локальная очередь.  

• Если и в локальной очереди ничего нет, снова проверяется глобальная очередь.  

• Рутины в состоянии "рейтинг" ожидают ответа от системы.  

• Эти рутины не могут выполняться, даже если освободится тред.  

• Рутины в состоянии "рейтинг" попадают в специальную очередь внутри канала.  

• Введение локальных очередей может привести к проблеме простаивающих трендов.  

• Если у одного процессора много работы, а у другого нет, возникает проблема.  

• Решение: процессор с работой "ворует" рутины у процессора без работы.  

• Процессор "ворует" половину рутин из локальной очереди другого процессора.  

• Это позволяет сбалансировать работу между процессорами.  

• Алгоритм поиска работы: проверка глобальной очереди, локальной очереди, ворсинг работы.  

• Рутины, выполняющие блокирующие операции, переходят в состояние "уйтинг".  

• Это приводит к простою процессора и системного треда.  

• Решение: создание нового треда для выполнения работы.  

• Каждый скол создает новый тред.  

• Это может привести к созданию множества трендов, что создает проблемы с памятью и производительностью.  

• Важно понимать фундаментальные ограничения операционной системы для оптимизации работы.  

• Планировщик оптимизирует работу, чтобы избежать создания новых тредов для коротких вызовов.  

• Если вызов короткий, система ждет его завершения, не создавая новый тред.  

• Если вызов длительный, система выполняет хэндов, чтобы освободить процессор.  

• Системный монитор ССМОН отслеживает время выполнения вызовов.  

• Если время превышает лимит, ССМОН выполняет хэндов.  

• ССМОН выполняется на отдельном служебном треде, чтобы не блокировать процессоры.  

• Отвязанный тред возвращается к процессору, если он свободен.  

• Если процессор занят, тред помещается в глобальный ран кью.  

• Модель планирования теперь называется ЭПН, с учетом спящих и системных тредов.  

• Операционные системы предоставляют механизмы для предотвращения блокировок тредов.  

• В Linux используется механизм JIT, который регистрирует вызовы в специальной системе.  

• Тред продолжает работать, пока вызов выполняется, и возвращается к системе для проверки ответа.  

• Не все вызовы могут выполняться синхронно, например, работа с файловой системой.  

• Сетевые вызовы могут выполняться синхронно, что позволяет избежать создания новых тредов.  

• Веб-серверы могут работать с множеством соединений, не нагружая операционную систему.  

• Рутины, ожидающие выполнения, переводятся в состояние "уйтинг" и регистрируются в "нетворк поре".  

• Ждущие рутины не занимают ресурсы процессора и не замедляют работу программы.  

• Процессор проверяет "нетворк пор" в конце своей работы, чтобы найти освободившиеся рутины.  

• Если у процессора много работы, он может не проверять "нетворк пор".  

• В этом случае "систем монитор" перемещает рутины в глобальную очередь, чтобы избежать простаивания.  

• Глобальная очередь защищена от простаивания, что решает проблему.  

• Механизм не полностью решает проблему, так как некоторые сколы невозможно делегировать.  

• Необходим воркер пул для ограничения количества рутин.  

• В будущем планируется отдельный ролик о реализации воркер пулов.  

• В Go многозадачность кооперативная, но версия 1.14 вызвала недопонимание.  

• Планировщик Go выполняет рутины по очереди, но может вытеснять рутины, если они выполняются слишком долго.  

• "Систем монитор" следит за рутинами и ставит флаг "стек гард", если рутина выполняется слишком долго.  

• Кооперативная многозадачность имеет недостаток: рутины могут игнорировать просьбы освободить место.  

• В версии 1.14 добавили возможность принудительного вытеснения рутин.  

• Функция "гомакс прок" определяет количество процессоров, используемых в программе.  

• Планировщик в Go позволяет загружать один процессор, что проще, чем несколько.  

• Программа может зависнуть, если не проверять состояние грудин.  

• Для решения проблемы нужны сигналы операционной системы.  

• Сигналы операционной системы позволяют прерывать выполнение программ.  

• Сигналы могут быть использованы для вытеснения неугодных рутин.  

• Рекомендуется изучить сигналы через пост в телеграм-канале автора.  

• Сигнал SIGURG используется редко и не мешает другим механизмам.  

• Он помогает прерывать рутины, выполняющиеся слишком долго.  

• Планировщик в Go стал кооперативным с элементами вытеснения.  

• Пакет runtime инициализирует процессоры и планировщик.  

• Функция gomaxpro возвращает количество процессоров.  

• Программа создает необходимое количество тредов операционной системы.  

• Программа выводит информацию о планировщике и процессорах.  

• Количество простаивающих процессоров и тредов.  

• Глобальная и локальные очереди рутин.  

• Программа запускается с тайм-слипом для анализа работы планировщика.  

• Количество процессоров и тредов изменяется в зависимости от выполнения программы.  

• Программа показывает, как планировщик управляет ресурсами.  

• В программе должно быть три треда: один на ссмон и по одному на каждый процессор.  

• Дополнительные треды могут создаваться рантаймом для экономии времени при нехватке ресурсов.  

• Это делается сразу при инициализации и может быть изменено в комментариях или чате.  

• Пять тредов не являются критичным количеством для современных программ.  

• Браузер может использовать десятки или сотни тредов.  

• Для проверки количества тредов используется функция ранта нам горутин.  

• Для создания дополнительной горутины используется префикс го.  

• Функция выполняет вечный цикл, чтобы не съедать процессор.  

• После запуска программы количество горутин увеличивается до двух.  

• Функция принт лн вызывает скол, что блокирует текущий тренд.  

• Скол короткий, поэтому не требуется дополнительный тренд для процессора.  

• В будущем будет рассмотрен механизм хондов и над пор.  

• Все горутины создаются внутри главной рутины и выпадают в локальную очередь процессора п ноль.  

• Процессоры п ноль и п один могут конкурировать за выполнение горутин.  

• Для определенности создается 256 горутин, которые распределяются по локальным и глобальной очередям.  

• В начале работы планировщика наблюдается дисбаланс, так как некоторые грудины вытесняются в глобальную очередь.  

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

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

• Для наглядного отображения работы планировщика создана утилита "гоша от виз".  

• Утилита автоматически запускает подопытную программу и парсит вывод для визуализации.  

• Утилита позволяет наблюдать значения более красиво и наглядно.  

• Для запуска утилиты нужно указать целевую программу и запустить "make build".  

• Утилита показывает количество грудин в глобальной очереди и других очередях.  

• Для получения общего количества грудин утилита экспортирует метрику.  

• Утилита визуализирует локальные очереди каждого процессора и количество грудин в них.  

• Показано количество тредов, используемых программами, и количество простаивающих процессоров.  

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

• Логарифмические графики помогают различать малые и большие значения.  

• Утилита доступна на GitHub с подробной инструкцией и примерами.  

• Подписчики телеграм-канала уже знакомы с утилитой и могут использовать её для экспериментов.  

• Процессоры постоянно балансируют работу благодаря "ворк стилю".  

• Большинство грудин выполняется в глобальной очереди.  

• Изменение количества грудин показывает, как планировщик справляется с нагрузкой.  

• При уменьшении количества грудин локальные очереди каждого процессора сильно увеличиваются.  

• Глобальная очередь уменьшается, но картина остается стабильной.  

• При уменьшении количества грудин меньше количества процессоров, все очереди начинают заполняться.  

• В системе мало работы, но много процессоров.  

• Все грудины выполняются на процессорах, очереди пустые.  

• ССмон иногда вытесняет грудины, даже если очередей нет.  

• В коде планировщика нет условий для вытеснения грудин.  

• Небольшие флуктуации в работе грудин не меняют глобальную картину.  

• Впервые за много запусков появились простаивающие процессоры.  

• Метрика idle processors колеблется между 3 и 4.  

• Процессоров 14, грудин 10, 4 процессора простаивают.  

• Возможно, метрика не успевает обновляться при переключении грудин.  

• Закомментировав полезную работу грудин, метрика idle processors остается неизменной.  

• Простаивающие процессоры остаются фиксированным значением.  

• Это подтверждает гипотезу о флуктуациях.  

• В системе всего 5 тредов, 3 из которых простаивают.  

• Рантайм не создает дополнительные треды для простаивающих процессоров.  

• При появлении работы, грудины будут выполняться на простаивающих тредах.  

• Хэндов создается, когда тред блокируется.  

• Новый тред создается, старый отправляется на отдых.  

• В программе с пятью процессорами и десятью грудинами создается двенадцать тредов.  

• Грудины выполняют вечный скол, который не завершается.  

• Планировщик не может поручить этот скол нет спойлеру, что приводит к созданию хэндова.  

• Грудины и их треды отправляются на отдых, создавая двенадцать тредов.  

• При увеличении количества грудин до пятидесяти создается пятьдесят два треда.  

• При создании двухсот пятидесяти тредов программа завершается.  

• Эксперимент с большим количеством тредов показывает, что программа не может их обрабатывать.  

• Нет спойлер позволяет избежать создания большого количества тредов.  

• В примере с сервером и клиентом создается 152 грудины и 16 тредов.  

• Нет спойлер освобождает треды, что позволяет избежать перегрузки системы.  

• Нет спойлер позволяет избежать блокировки тредов.  

• Все процессоры простаивают, так как нет активных рутин.  

• При отключении клиента сервер теряет входящие соединения, что подтверждает актуальность информации о грудинах.  

• Мьютексы могут снижать производительность программ, заставляя процессоры ждать освобождения мьютекса.  

• Пример программы с четырьмя процессорами и воркерами показывает, что мьютексы приводят к простоям.  

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

• Глобальная очередь приводит к простоям процессоров, ожидающих освобождения мьютекса.  

• Локальные очереди для каждого процессора помогают избежать этих проблем.  

• Проектирование программ должно избегать создания мьютексов, если это возможно.  

• Видео завершается обсуждением планировщика и его работы.  

• Для более глубокого понимания планировщика рекомендуется подписаться на платные каналы автора.  

• В платных каналах будут доступны ролики с более детальным разбором планировщика и его исходников.  

• Планировщик операционной системы управляет ядрами компьютера и системными тредами.  

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

• Процессоры берут задачи из локальных очередей и выполняют их на тредах.  

• Глобальная очередь используется, когда у одного из процессоров заканчиваются задачи.  

• Нет спойлер помогает процессорам выполнять сетевые операции без блокировки.  

• Механизм хэндов создает дополнительные треды для выполнения длительных операций.  

• Видео объясняет работу планировщика и его механизмы.  

• Автор благодарит зрителей за просмотр и поддержку.  

• Призывает подписываться на платные каналы и делиться видео в социальных сетях.