А почему, собственно, потоки операционной системы не могут быть столь же эффективны, как и горутины? То есть почему разработчики OS тоже не могут сделать динамический стек и другие оптимизации?
Здравствуйте, mrTwister, Вы писали:
T>А почему, собственно, потоки операционной системы не могут быть столь же эффективны, как и горутины? То есть почему разработчики OS тоже не могут сделать динамический стек и другие оптимизации?
1) Переключение контекста не бесплатное
2) Каждый поток кушает 1МБ под стек минимум
В основном потому что ОС не знает чем будет заниматься поток и делает многое "по умолчанию".
В Винде уже давно есть возможность создавать пулы потоков, очереди задач, ожидания IO и таймеров, что позволяет иметь много потоков в программе при минимуме потоков в ОС.
Здравствуйте, gandjustas, Вы писали:
G>1) Переключение контекста не бесплатное
А в GO бесплатное? Почему OS не может делать как в GO Runtime?
G>2) Каждый поток кушает 1МБ под стек минимум
Почему OS не может делать динамический размер стека, как GO Runtime?
G>В основном потому что ОС не знает чем будет заниматься поток и делает многое "по умолчанию".
А каких именно знаний о потоке не хватает OS?
Здравствуйте, mrTwister, Вы писали:
G>>1) Переключение контекста не бесплатное T>А в GO бесплатное? Почему OS не может делать как в GO Runtime?
Большинство переключений в рантайме не выходят за рамки юзерланда.
При переключении через ОС неизбежно прохождение через ядро. В системах, где системный вызов дорог, это даёт существенные затраты.
Кроме того, во многих ОС ради изоляции процессов сделано много защит (особенно это важно в плане последних Meltdown/Spectre — при переключении могут сбрасывать целиком кэши) и не сделано оптимизации этого в случае переключения между нитями одного процесса. В Windows это ещё сложнее сделать потому, что в отличие от всех Unix систем права доступа могут быть разными для разных нитей, поэтому количество действий при переключении существенно увеличивается.
G>>2) Каждый поток кушает 1МБ под стек минимум T>Почему OS не может делать динамический размер стека, как GO Runtime?
Вообще-то давно есть подходы типа split stack. Но они дорогие за счёт проверки необходимости такого сплита на каждом вызове функции.
В случае управляемых рантаймов, как в Go, Erlang и тому подобных, рантайм имеет возможность в случае разбухания стека переаллоцировать его целиком, исправив адреса возврата. ОС не имеет данных для этого и в результате не имеет права двигать стек.
G>>В основном потому что ОС не знает чем будет заниматься поток и делает многое "по умолчанию". T>А каких именно знаний о потоке не хватает OS?
Например, по каждому байту в стеке, что он означает — данное или адрес, а если адрес, то что за этим адресом и как им можно управлять (можно ли двигать, двигает ли кто-то из самого процесса...)
Это ссылка ни о чём. Всё то кэпство, что там написано, или идентично для всех переключений включая чисто userland, или может быть устранено (как минимум в Unix) при переключении между нитями одного процесса. Что может пойти не так при переключении на другую нить — составляет малую часть этого набора (если это не случай "имперсонации" в другой процесс в Windows).
S> Длительность, размер стека. Кроме того есть TLS https://docs.microsoft.com/ru-RU/cpp/parallel/thread-local-storage-tls?view=msvc-160&viewFallbackFrom=vs-2017
TLS аж ничем не мешает. При переключении на другую нить меняется, в современных реализациях, регистр FS или GS. По адресу в этом регистре находится персональная область конкретной нити.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>1) Переключение контекста не бесплатное T>А в GO бесплатное? Почему OS не может делать как в GO Runtime?
По сравнению с ОС — бесплатное.
К сожалению не знаю как работет ГО рантайм.
G>>2) Каждый поток кушает 1МБ под стек минимум T>Почему OS не может делать динамический размер стека, как GO Runtime?
В ОС тоже динамический, начинается с 1 МБ. Это число видимо результат большого количеста исследований.
G>>В основном потому что ОС не знает чем будет заниматься поток и делает многое "по умолчанию". T>А каких именно знаний о потоке не хватает OS?
ОС не знает когда поток остановится и остановится ли вообще. ОС прерывает выполнение по кванту времени, поэтому нужно сохвранить все текуще состояние (стек). В "упавлемых" средах "поток" выполнения останавливается не тогда когда ОС решит, а тогда когда код дойдет до точки прерывания. В этой точке рантайм знает о текущем состоянии "потока", которое обычно в разы меньше чем весь стек.
Здравствуйте, gandjustas, Вы писали:
G>>>В основном потому что ОС не знает чем будет заниматься поток и делает многое "по умолчанию". T>>А каких именно знаний о потоке не хватает OS? G>ОС не знает когда поток остановится и остановится ли вообще.
Ну кроме случаев, когда нить сама делает вызов, который блокирует её выполнение )
а таких действий в сетевой нагрузке и GUI, например, большинство.
G> ОС прерывает выполнение по кванту времени, поэтому нужно сохвранить все текуще состояние (стек).
При любом прерывании выполнения надо сохранить текущее состояние.
G> В "упавлемых" средах "поток" выполнения останавливается не тогда когда ОС решит, а тогда когда код дойдет до точки прерывания.
И как определяется точка прерывания?
В Go это точно так же как в случае ОС — переход в ожидание, или просто вызов чего-то в рантайме. Пустой вечный цикл в Go заблокирует целиком одну системную нить рантайма.
В Erlang не так — там рантайм считает "редукции", но за это платится тратой процессора.
G> В этой точке рантайм знает о текущем состоянии "потока", которое обычно в разы меньше чем весь стек.
Оно ровно равно тут всему стеку плюс регистры (а не пространству, зарезервированному под стек).
Здравствуйте, netch80, Вы писали:
G>>ОС не знает когда поток остановится и остановится ли вообще. N>Ну кроме случаев, когда нить сама делает вызов, который блокирует её выполнение ) N>а таких действий в сетевой нагрузке и GUI, например, большинство.
А конкретнее?
Если что планировщики ОС всгеда нормально справлялись с десктопной нагрузкой. необходимость обращатся с огромным количеством потоков есть только в сервреах.
G>> ОС прерывает выполнение по кванту времени, поэтому нужно сохвранить все текуще состояние (стек). N>При любом прерывании выполнения надо сохранить текущее состояние.
Только "контролируемое" прерывание потребует гораздо меньше места для сохраннеия, чем прерывание в произвольном месте.
G>> В "упавлемых" средах "поток" выполнения останавливается не тогда когда ОС решит, а тогда когда код дойдет до точки прерывания. N>И как определяется точка прерывания? N>В Go это точно так же как в случае ОС — переход в ожидание, или просто вызов чего-то в рантайме. Пустой вечный цикл в Go заблокирует целиком одну системную нить рантайма.
Это фактически означает что планирощик Го не может использоваться в ОС для всех потоков.
N>Оно ровно равно тут всему стеку плюс регистры (а не пространству, зарезервированному под стек).
В C# можно в явном виде увидеть состояние "продожения" в async\await, оно сильно меньше чем весь стек + регистры.
Здравствуйте, netch80, Вы писали:
N>В Go это точно так же как в случае ОС — переход в ожидание, или просто вызов чего-то в рантайме. Пустой вечный цикл в Go заблокирует целиком одну системную нить рантайма.
Не заблокирует, начиная с версии 1.14 в Go реализована вытесняющая многозадачность, рантайм переключает горутины в произвольные моменты времени независимо от того, что они делают
Здравствуйте, gandjustas, Вы писали:
G>ОС не знает когда поток остановится и остановится ли вообще. ОС прерывает выполнение по кванту времени, поэтому нужно сохвранить все текуще состояние (стек). В "упавлемых" средах "поток" выполнения останавливается не тогда когда ОС решит, а тогда когда код дойдет до точки прерывания. В этой точке рантайм знает о текущем состоянии "потока", которое обычно в разы меньше чем весь стек.
В Go все тоже самое начиная с версии 1.14, там нет больше никаких точек прерывания, рантайм переключает горутины, когда ему захочется
Здравствуйте, gandjustas, Вы писали:
G>В C# можно в явном виде увидеть состояние "продожения" в async\await, оно сильно меньше чем весь стек + регистры.
А зачем весь стек сохранять, почему регистров недостаточно?
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>В C# можно в явном виде увидеть состояние "продожения" в async\await, оно сильно меньше чем весь стек + регистры.
T>А зачем весь стек сохранять, почему регистров недостаточно?
Работает поток: вызвал функцию А, она функцию Б, она функцию В. Произошло прерывание. Через пару десятков мсек возвращает правление потоку 1, возвращает стек на место, возвращает регистры и thread local значения. И функция В как ни в чем не бывало продолжает выполняться, возвращает управление функции Б, а та в свою очрередь функции А.
В async\await все переменные, используемые после прерывания, попадают в "состояние". Стек вызовов не хранится, а хранится только номер точки прерывания в каждой функции в цепочки вызовов и в switch по этому номеру функция продожает выполняться с точки прерывания.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, netch80, Вы писали:
N>>В Go это точно так же как в случае ОС — переход в ожидание, или просто вызов чего-то в рантайме. Пустой вечный цикл в Go заблокирует целиком одну системную нить рантайма.
T>Не заблокирует, начиная с версии 1.14 в Go реализована вытесняющая многозадачность, рантайм переключает горутины в произвольные моменты времени независимо от того, что они делают
А зачем? ОС справляется хуже? Или сам по коду точки прерывания расставляет?
Ок, спасибо, стало яснее. Но тогда разработчики ОС могли бы, например, предоставить возможность запускать легковесные потоки отдельно от старых тяжеловесных, введя ограничение на безопасность таких потоков и необходимость предоставлять информацию по разметке стека.
Здравствуйте, gandjustas, Вы писали:
G>Работает поток: вызвал функцию А, она функцию Б, она функцию В. Произошло прерывание. Через пару десятков мсек возвращает правление потоку 1, возвращает стек на место, возвращает регистры и thread local значения. И функция В как ни в чем не бывало продолжает выполняться, возвращает управление функции Б, а та в свою очрередь функции А.
Стек сам вернется после возвращения стековых регистров, память процесса же не стирается.
Содержимое кэша (особенно это касается кэша первого уровня), накопленное и «оптимизированное» под выполнение одного потока, оказывается совершенно неприменимым к новому потоку, на который происходит переключение.
При переключении контекста на процесс, который до этого долгое время не использовался (см. Подкачка страниц), многие страницы могут физически отсутствовать в оперативной памяти, что порождает подгрузку вытесненных страниц из вторичной памяти.
С точки зрения прикладного уровня переключение контекста можно разделить на добровольное (voluntary) и принудительное (non-voluntary): выполняющийся процесс/поток может сам передать управление другому потоку либо ядро может насильно отобрать у него управление.
Ядро ОС может отобрать управление у выполняющегося процесса/потока при истечении кванта времени, выделенного на выполнение. С точки зрения программиста это означает, что управление могло уйти от потока в «самый неподходящий» момент времени, когда структуры данных могут находиться в противоречивом состоянии из-за того, что их изменение не было завершено.
Выполнение блокирующего системного вызова. Когда приложение производит ввод-вывод, ядро может решить, что можно отдать управление другому потоку/процессу в ожидании, пока запрошенный данным потоком дисковый либо сетевой ввод-вывод будет выполнен. Данный вариант является самым производительным.
Синхронизирующие примитивы ядра. Мьютексы, Семафоры и т. д. Это и есть основной источник проблем с производительностью. Недостаточно продуманная работа с синхронизирующими примитивами может приводить к десяткам тысяч, а в особо запущенных случаях — и к сотням тысяч переключений контекста в секунду. [источник не указан 2456 дней]
Системный вызов, явно ожидающий наступления события (select, poll, epoll, pause, wait,…) либо момента времени (sleep, nanosleep,..). Данный вариант является относительно производительным, так как ядро ОС имеет информацию об ожидающих процессах.
Поэтому async await то есть задачи предпочтительнее потоков
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>Работает поток: вызвал функцию А, она функцию Б, она функцию В. Произошло прерывание. Через пару десятков мсек возвращает правление потоку 1, возвращает стек на место, возвращает регистры и thread local значения. И функция В как ни в чем не бывало продолжает выполняться, возвращает управление функции Б, а та в свою очрередь функции А.
T>Стек сам вернется после возвращения стековых регистров, память процесса же не стирается
То есть стеки всех потоков хранятся в одном адресном пространстве?
)