Comments 4
Я полностью читать не стал. Особенно с картинки 1 ничё непонятно уже сразу. По простому, на уровне железа можно уточнить? Есть процесс, есть внутри него тред, а в треде функции (рутины). Они обычно выполняются одна за другой (поток исполнения вошел в одну, вышел из неё, зашел в следующую), а в случае конкурентности у таких рутин (помеченных как "go") появляется свойство сохранять своё состояние на регистрах (где-то там, в общем). В итоге поток исполнения зашел, поработал, сохранил состояние в середине, вышел зашел в другую рутину, вышел опять, загрузил состояние первой и тд. Правильно я это понимаю?
А скедулер просто, в случае I/O операции в первой рутине перекидывает на другой тред оставшиеся рутины (в очередь глобальную и из неё доп тред забирает)? Ну очень упрощённо.
Но, это же тогда не оптимальное исполнение, а "тупое" скедулирование по избыточности. По умному надо давать скедулеру на вход время исполнения каждой операции (все типовые вполне известны) и флаги "не раньше"/"не позднее", когда их нужно исполнить. Вот тогда и утилизацию ЦП можно будет довести до адекватных значений, а не получать "традиционные" 1,5 ядра из 32-х. ))
А скедулер просто, в случае I/O операции в первой рутине перекидывает на другой тред оставшиеся рутины (в очередь глобальную и из неё доп тред забирает)? Ну очень упрощённо.
Нет, если делать так — можно даже и не стараться делить потоки. Смысл легковесных потоков/горутин/асинхронности — как раз в том, чтобы потоки не ждали на задачах ввода-вывода, для чего весь ввод-вывод в стандартной библиотеке делается через шаблон "Проактор" и такие механизмы системы как epoll или IOCP.
Планирование в Go: Часть III — Конкурентность