Почему горутина так мало весит?

Question

[Дмитрий]

В спецификации текущей версии написанно, что начальный размер горутины = 2кб.
В то же время, они основаны на системных потоках, размер которых не меньше 1Мб.

Почему основываясь на системном потоке, программа с одной горутиной занимает всего 2кб?

Comments

[raiboon]

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

[Дмитрий]

raiboon, тогда что из себя представляет горутина для ОС?

[raiboon]

ос их не видит, они существуют исключительно в рантайме го
для оси - просто несколько (gomaxproc) потоков, которые постоянно что-то делают

[Дмитрий]

для оси - просто несколько (gomaxproc) потоков, которые постоянно что-то делают

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

[Roman K]

Иван Волков, нет, размер программы будет минимум суммой размеров стеков всех горутин и размеров стеков системных потоков, которых может быть один или больше вплоть до gomaxprocs (на самом деле больше, т.к. это значение не включает, например, тред для парковки горутин, ожидающих syscall'ы). В то же время, стек 1мб (или 4мб для 64 бит) не означает, что эти 1(4) мб будут заняты физически, потому что они выделяются в виртуальной памяти

[Дмитрий]

Roman Kitaev, понял, спасибо

Answer 1

[Roman K]

В то же время, они основаны на системных потоках, размер которых не меньше 1Мб.

Вот в этом главное заблуждение. Горутины не основаны на системных потоках, системные потоки исполняют горутины. Горутина — это "задача", поток — "исполнитель". Исполнитель может исполнять задачу, пока она не будет выполнена или пока исполнителю есть что делать (а не ждать сеть или диск, например). После этого исполнитель ищет новую задачу. Для этого у него есть своя очередь задач. Если в ней что-то есть — исполняется это "что-то" (другая горутина). Если нет — исполнитель идёт в "глобальную очередь" и выгребает оттуда немного задач (больше одной). Если и в той очереди ничего нет, он идёт "воровать" (да, это буквально так называется — stealing) задачи из очередей других исполнителей (соседних потоков).

Так вот, поток далеко не равно горутина. У потока системный стек, у горутины — какой захочет рантайм го.

Comments

[Дмитрий]

То есть в Go реализованны свои потоки (горутины), которые основываются на ...

[Дмитрий]

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

[Roman K]

Иван Волков,

То есть в Go реализованны свои потоки (горутины), которые основываются на ...

Смекалке разработчиков языка

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

чего?

[Дмитрий]

Roman Kitaev, то есть в Go созданы свои "потоки", которые никак не связаны с потоками ОС и вся конкурентность лежит на планировщике Go?

[Roman K]

Иван Волков, бинго!

[Дмитрий]

Roman Kitaev, честно говоря, вопросов теперь еще больше, но на них ток исходники ответить смогут :)

Answer 2

[uvelichitel]

Гуглить greenthreads, user space threads. Такое не только Go умеет. Архитектурно, конкретно Go берёт истоки в Plan9, можно почитать например https://9fans.github.io/plan9port/man/man3/thread.html
Планировщик user space потоков похож на системный планировщик pthreads. Но в системных потоках, если совсем грубо, при переключении контекста нужно сохранить регистры, стек и кучу(heap). В легковесных user space потоках куча общая для всех. Память для сохранения стека при переключении контекста системный планировщик выделяет сразу с запасом. А планировщик Go runtime выделяет, без запаса, всего 2кб с возможностью роста. (Между прочим много кода и архитектуры в планировщик Go занёс соотечественник -- Дмитрий Вьюков. 2кб вроде его персональная заслуга)