Прежде чем смотреть на время планировщика Go, мы должны понять , почему вам это нужно, потому что мы могли бы думать, ядро ОС не уже планировщик потоков Ну?
POSIX API , знакомые люди знают, программа POSIX в основном модель процесса подхода Unix является логическим описанием и расширения, оба имеют много общих черт. Тема имеет свою собственную маску сигнала, сродство процессора и так далее. Но многие особенности программы Go как для громоздких. трудоемкая Особый контекст переключения контекста. Другая причина заключается в том , что сбор мусора нужно идти по всему goroutine остановился так , что память в целостном состоянии. Garbage пункт сбора во время является неопределенным, если операционная система использует свой собственный планировщик на график, то будет большое количество потоков , необходимо прекратить работу.
GO был отдельный планировщик развития может знать , когда его состояние памяти одно и то же, то есть, когда мы начинаем собирать мусор, работает просто ждать , что поток для запуска на ядре было на процессоре, а не ждать для всех потоков. Отображение отношения между пространством пользователя и пространством ядра резьбы имеет резьбы: N: 1,1: 1 и M: N. N: 1 является то , что несколько (N) пользовательские потоки всегда выполняются в ядре потока, контекст контекстные переключения очень быстро, но не реальное преимущество многоядерности. 1: 1 является то , что пользователь нить работать только на поток ядра, то вы можете воспользоваться многоядерность, но очень медленно переключение контекста. M: N есть, goroutine несколько потоков для работы на нескольких ядрах, это , как представляется сборка из указанных выше преимуществ обоих, но увеличит сложность планирования.
Перейти в планировщике имеет три важных структурных: M, P, G
M: представляет потоков ядра реального ОС и POSIX нить в почти реальном трудящихся
G: представляет goroutine, он имеет свой собственный стек, инструкция указатель и другая информация (ожидание канала и т.д.), для планирования.
P: планирование от имени контекста, его можно рассматривать как локальный планировщик, чтобы идти, чтобы запустить код на нити, которая достигается с N: 1 до N: отображение ключа M.
На фигуре видна, существует два М физических потоков, каждый из М имеет контекст (P), каждый из них также имеет goroutine ход.
Число P может быть установлено GOMAXPROCS (), которая на самом деле она представляет собой реальную степень параллелизма, то есть сколько goroutine могут работать одновременно. Goroutine серая фигура, не бежать, но готов к готовности, мы ждем , чтобы быть запланированы. P поддерживает очередь ( так называемый runqueue), Go язык, начать goroutine легко: идти функцию на линии, так что есть идти каждый оператор выполняются, runqueue присоединился к goroutine очереди в конце своего следующего пункта планирования, удалить его (как решить , что взять goroutine?) из runqueue в исполнении goroutine.
Зачем поддерживать множественные контексты P? Поскольку ОС , когда поток блокируется, P может вместо этого перешел на другую ОС нить! Мы видим фигуру, когда нить OS являются засорение M0, P вместо запуска на OS нить M1. Планировщик для обеспечения есть достаточно потоков для выполнения всех контекстов P.
M1 фигуры могут быть созданы или удалены из кэша потоков. Когда вернется MO, он должен попытаться получить контекст P goroutine в перспективе, при нормальных обстоятельствах, было бы от других потоков ОС , где крадут украсть контекст здесь, если бы я не крал его, наложив на глобальном runqueue в goroutine а затем лег спать сам великий сон (в кэш потоков). Контексты также периодически проверять глобальный runqueue, иначе goroutine на глобальном runqueue никогда не выполняется.
Другой случай поставлена задача P G закончил быстро выполняется (неравномерное распределение), что приводит к P системе сухости контекста холостой ходу все в порядок, но любой курс занят. Но если нет глобальной runqueue задачи G, то P придется подобрать какой - нибудь другой контекст G от P для выполнения там. В общем, если контекст из другого контекста P P есть украсть задачу, то, как правило , «украсть» запустить половину очереди, которая гарантирует , что каждая ОС нить может полностью использовать.
