Сообщение Re[8]: Киллер фича JDK 21 - virtual threads от 02.06.2023 6:35
Изменено 02.06.2023 6:40 vdimas
Re[8]: Киллер фича JDK 21 - virtual threads
Здравствуйте, Serginio1, Вы писали:
S>Интересно а как сосуществуют виртуальные потоки с тасками?
S>https://learn.microsoft.com/en-us/dotnet/api/system.threading.asynclocal-1?redirectedfrom=MSDN&view=net-7.0
Во-первых, не "виртуальные потоки", а Fibers, они же "зеленые потоки", если управление ими осуществляется прозрачно некоей платформой/RTL/VM.
Какой двоечник придумал термин "виртуальные потоки" — это полный П. ))
Во-вторых, Fibers — это stackfull coroutines, а дотнетные таски — stateless coroutines.
С практической т.з. разница в том, что стековые корутины могут быть прерваны и продолжены на любой глубине вызова своего кода, а бесстековые могут прерываться и продолжаться только на верхнем уровне, где продолжение порой намного дороже предыдущего прерывания, т.к. необходимо осуществлять роутинг по состояниям вложенных автоматов, если логически код бесстековой корутины прерывался на вложенных своих вызовах.
Технически стековым корутинам выделяется стек и при их переключении происходит сохранение-загрузка регистров.
А бесстековая корутина — это детерминированный автомат (не обязательно конечный, но чаще конечный).
Кстате, в и-нетах разлито довольно много идиотизма насчет зеленых потоков, например:
https://habr.com/ru/articles/543158/
Далее в статье рассуждения о вытесняющей или нет многозадачности — там тоже сплошная каша и непонимание.
И такого бреда в и-нете полно, почему-то.
"А на самом деле..." (С)
Всё проще, на самом деле.
"Обычные потоки вытесняющие" — не совсем.
Обычные треды тоже могут кооперативно передавать управление, в АПИ любой ОС есть соотв. ср-ва, например, SwitchToThread, pthread_yield.
"Зеленые потоки кооперативные" — не совсем.
Зеленый поток может быть вытеснен вместе со своим хостовым потоком уровня ОС.
Основная разница этих подходов в том, что потоки уровня ядра переключаются ядром и это дороже по двум всего причинам:
— переключение контекста текущего процесса, что дорого в ОС, работающих в защищённом режиме, т.е. с виртуальной памятью;
— ядро управляет очередью, где тусят все потоки всех процессов.
В случае зелёных/легких потоков, ситуация чуть другая:
— при их переключении не переключается контекст исполнения процессора/ядра, т.е. не переотображается виртуальная память (задержки переключения контекста именно тут);
— процесс занимается планировкой небольшой очереди легковесных потоков, в сравнении с ситуацией, где все бы процессы скидывали бы все свои тысячи уже нелёгких потоков в общую очередь.
Описанные трюки относится не только к потокам, конечно, но и к таймерам, к примитивам синхронизации и т.д.
Например, дешевле иметь свою очередь таймеров уровня процесса, если этих таймеров много, чтобы не засорять общую очередь таймеров уровня ядра.
Аналогично, если много семафоров.
Аналогично, если много сокетов — тогда на юзверский уровень вытаскивают из драйвера уровня ядра только сырые пакеты, а весь диспатчинг IO уже происходит на уровне процесса, с обыгрыванием высокоуровневых протоколов, типа TCP/UDP/IP.
S>Интересно а как сосуществуют виртуальные потоки с тасками?
S>https://learn.microsoft.com/en-us/dotnet/api/system.threading.asynclocal-1?redirectedfrom=MSDN&view=net-7.0
Во-первых, не "виртуальные потоки", а Fibers, они же "зеленые потоки", если управление ими осуществляется прозрачно некоей платформой/RTL/VM.
Какой двоечник придумал термин "виртуальные потоки" — это полный П. ))
Во-вторых, Fibers — это stackfull coroutines, а дотнетные таски — stateless coroutines.
С практической т.з. разница в том, что стековые корутины могут быть прерваны и продолжены на любой глубине вызова своего кода, а бесстековые могут прерываться и продолжаться только на верхнем уровне, где продолжение порой намного дороже предыдущего прерывания, т.к. необходимо осуществлять роутинг по состояниям вложенных автоматов, если логически код бесстековой корутины прерывался на вложенных своих вызовах.
Технически стековым корутинам выделяется стек и при их переключении происходит сохранение-загрузка регистров.
А бесстековая корутина — это детерминированный автомат (не обязательно конечный, но чаще конечный).
Кстате, в и-нетах разлито довольно много идиотизма насчет зеленых потоков, например:
https://habr.com/ru/articles/543158/
У автора кукушка малость протекла, бессмысленный набор звуков. ))Грин треды решают общую проблему в программировании — вам не хочется, чтобы ваш код блокировал процессор, растрачивая ресурсы. Решается это использованием многозадачности, которая позволяет приостановить выполнение одного участка кода, запуская на выполнение другой, переключаясь между "контекстами".
Легко спутать с параллелизмом, но не делайте этого — это две совершенно разные вещи. Параллелизм — это как забрасывание проблемы вычислительными ресурсами. Грин треды позволяют работать умнее и эффективнее, эффективнее расходовать ресурсы.
Далее в статье рассуждения о вытесняющей или нет многозадачности — там тоже сплошная каша и непонимание.
И такого бреда в и-нете полно, почему-то.
"А на самом деле..." (С)
Всё проще, на самом деле.
"Обычные потоки вытесняющие" — не совсем.
Обычные треды тоже могут кооперативно передавать управление, в АПИ любой ОС есть соотв. ср-ва, например, SwitchToThread, pthread_yield.
"Зеленые потоки кооперативные" — не совсем.
Зеленый поток может быть вытеснен вместе со своим хостовым потоком уровня ОС.
Основная разница этих подходов в том, что потоки уровня ядра переключаются ядром и это дороже по двум всего причинам:
— переключение контекста текущего процесса, что дорого в ОС, работающих в защищённом режиме, т.е. с виртуальной памятью;
— ядро управляет очередью, где тусят все потоки всех процессов.
В случае зелёных/легких потоков, ситуация чуть другая:
— при их переключении не переключается контекст исполнения процессора/ядра, т.е. не переотображается виртуальная память (задержки переключения контекста именно тут);
— процесс занимается планировкой небольшой очереди легковесных потоков, в сравнении с ситуацией, где все бы процессы скидывали бы все свои тысячи уже нелёгких потоков в общую очередь.
Описанные трюки относится не только к потокам, конечно, но и к таймерам, к примитивам синхронизации и т.д.
Например, дешевле иметь свою очередь таймеров уровня процесса, если этих таймеров много, чтобы не засорять общую очередь таймеров уровня ядра.
Аналогично, если много семафоров.
Аналогично, если много сокетов — тогда на юзверский уровень вытаскивают из драйвера уровня ядра только сырые пакеты, а весь диспатчинг IO уже происходит на уровне процесса, с обыгрыванием высокоуровневых протоколов, типа TCP/UDP/IP.
Re[8]: Киллер фича JDK 21 - virtual threads
Здравствуйте, Serginio1, Вы писали:
S>Интересно а как сосуществуют виртуальные потоки с тасками?
S>https://learn.microsoft.com/en-us/dotnet/api/system.threading.asynclocal-1?redirectedfrom=MSDN&view=net-7.0
Во-первых, не "виртуальные потоки", а Fibers, они же "зеленые потоки", если управление ими осуществляется прозрачно некоей платформой/RTL/VM.
Какой двоечник придумал термин "виртуальные потоки" — это полный П. ))
Во-вторых, Fibers — это stackfull coroutines, а дотнетные таски — stateless coroutines.
С практической т.з. разница в том, что стековые корутины могут быть прерваны и продолжены на любой глубине вызова своего кода, а бесстековые могут прерываться и продолжаться только на верхнем уровне, где продолжение порой намного дороже предыдущего прерывания, т.к. необходимо осуществлять роутинг по состояниям вложенных автоматов, если логически код бесстековой корутины прерывался на вложенных своих вызовах.
Технически стековым корутинам выделяется стек и при их переключении происходит сохранение-загрузка регистров.
А бесстековая корутина — это детерминированный автомат (не обязательно конечный, но чаще конечный).
Кстате, в и-нетах разлито довольно много идиотизма насчет зеленых потоков, например:
https://habr.com/ru/articles/543158/
Далее в статье рассуждения о вытесняющей или нет многозадачности — там тоже сплошная каша и непонимание.
И такого бреда в и-нете полно, почему-то.
"А на самом деле..." (С)
Всё проще, на самом деле.
"Обычные потоки вытесняющие" — не совсем.
Обычные треды тоже могут кооперативно передавать управление, в АПИ любой ОС есть соотв. ср-ва, например, SwitchToThread, pthread_yield.
"Зеленые потоки кооперативные" — не совсем.
Зеленый поток может быть вытеснен вместе со своим хостовым потоком уровня ОС.
Основная разница этих подходов в том, что потоки уровня ядра переключаются ядром и это дороже по двум всего причинам:
— переключение контекста текущего процесса, что дорого в ОС, работающих в защищённом режиме, т.е. с виртуальной памятью;
— ядро управляет очередью, где тусят все потоки всех процессов.
В случае зелёных/легких потоков, ситуация чуть другая:
— при их переключении не переключается контекст исполнения процессора/ядра, т.е. не переотображается виртуальная память (задержки переключения контекста именно тут);
— процесс занимается планировкой небольшой очереди легковесных потоков, в сравнении с ситуацией, где все бы процессы скидывали бы все свои тысячи уже нелёгких потоков в общую очередь.
Описанные трюки относится не только к потокам, конечно, но и к таймерам, к примитивам синхронизации и т.д.
Например, дешевле иметь свою очередь таймеров уровня процесса если этих таймеров много, чтобы не засорять общую очередь таймеров уровня ядра.
Аналогично, если много семафоров.
Аналогично, если много сокетов — тогда на юзверский уровень вытаскивают из драйвера уровня ядра только сырые пакеты, а весь диспатчинг IO уже происходит на уровне процесса, с обыгрыванием высокоуровневых протоколов, типа TCP/UDP/IP.
S>Интересно а как сосуществуют виртуальные потоки с тасками?
S>https://learn.microsoft.com/en-us/dotnet/api/system.threading.asynclocal-1?redirectedfrom=MSDN&view=net-7.0
Во-первых, не "виртуальные потоки", а Fibers, они же "зеленые потоки", если управление ими осуществляется прозрачно некоей платформой/RTL/VM.
Какой двоечник придумал термин "виртуальные потоки" — это полный П. ))
Во-вторых, Fibers — это stackfull coroutines, а дотнетные таски — stateless coroutines.
С практической т.з. разница в том, что стековые корутины могут быть прерваны и продолжены на любой глубине вызова своего кода, а бесстековые могут прерываться и продолжаться только на верхнем уровне, где продолжение порой намного дороже предыдущего прерывания, т.к. необходимо осуществлять роутинг по состояниям вложенных автоматов, если логически код бесстековой корутины прерывался на вложенных своих вызовах.
Технически стековым корутинам выделяется стек и при их переключении происходит сохранение-загрузка регистров.
А бесстековая корутина — это детерминированный автомат (не обязательно конечный, но чаще конечный).
Кстате, в и-нетах разлито довольно много идиотизма насчет зеленых потоков, например:
https://habr.com/ru/articles/543158/
У автора кукушка малость протекла, бессмысленный набор звуков. ))Грин треды решают общую проблему в программировании — вам не хочется, чтобы ваш код блокировал процессор, растрачивая ресурсы. Решается это использованием многозадачности, которая позволяет приостановить выполнение одного участка кода, запуская на выполнение другой, переключаясь между "контекстами".
Легко спутать с параллелизмом, но не делайте этого — это две совершенно разные вещи. Параллелизм — это как забрасывание проблемы вычислительными ресурсами. Грин треды позволяют работать умнее и эффективнее, эффективнее расходовать ресурсы.
Далее в статье рассуждения о вытесняющей или нет многозадачности — там тоже сплошная каша и непонимание.
И такого бреда в и-нете полно, почему-то.
"А на самом деле..." (С)
Всё проще, на самом деле.
"Обычные потоки вытесняющие" — не совсем.
Обычные треды тоже могут кооперативно передавать управление, в АПИ любой ОС есть соотв. ср-ва, например, SwitchToThread, pthread_yield.
"Зеленые потоки кооперативные" — не совсем.
Зеленый поток может быть вытеснен вместе со своим хостовым потоком уровня ОС.
Основная разница этих подходов в том, что потоки уровня ядра переключаются ядром и это дороже по двум всего причинам:
— переключение контекста текущего процесса, что дорого в ОС, работающих в защищённом режиме, т.е. с виртуальной памятью;
— ядро управляет очередью, где тусят все потоки всех процессов.
В случае зелёных/легких потоков, ситуация чуть другая:
— при их переключении не переключается контекст исполнения процессора/ядра, т.е. не переотображается виртуальная память (задержки переключения контекста именно тут);
— процесс занимается планировкой небольшой очереди легковесных потоков, в сравнении с ситуацией, где все бы процессы скидывали бы все свои тысячи уже нелёгких потоков в общую очередь.
Описанные трюки относится не только к потокам, конечно, но и к таймерам, к примитивам синхронизации и т.д.
Например, дешевле иметь свою очередь таймеров уровня процесса если этих таймеров много, чтобы не засорять общую очередь таймеров уровня ядра.
Аналогично, если много семафоров.
Аналогично, если много сокетов — тогда на юзверский уровень вытаскивают из драйвера уровня ядра только сырые пакеты, а весь диспатчинг IO уже происходит на уровне процесса, с обыгрыванием высокоуровневых протоколов, типа TCP/UDP/IP.