Грубо говоря — по ссылкам утверждается, что весь IO поддерживается новой фичей, т.к. это наиболее сложная часть. Откуда следует, что новая фича только для ИО — не ясно, это ваша выдумка.
Здравствуйте, Gt_, Вы писали:
Gt_> интересный бот, но как и chatGPT совсем не держит контекст и не обучен синтаксису C#/Java, не может их различить.
Старенький он уже. Вроде ему 60+ афаик.
Здравствуйте, Serginio1, Вы писали:
S> Я тебе давал ссылку на твои слова. Ты сказал только об IO.
Приведи мои слова цитатой. С контекстом. И покажи где там "только".
S> Вот здесь товарищ привел все поддерживаемое http://rsdn.org/forum/philosophy/8525873.1
S> ·>Ну и какой смысл в ограниченном IO? S> Ограниченный в том, что нет TaskCompletionSource.
Ясно. Java IO ограничен тем, что в нём нет класса из c#. Невелика потеря. Или что ты сказать-то хотел?
S> А это в реале 90% всех асинхронных методов
У _тебя_ в коде 90% вызовов асинхронных, поверю. Просто другого выбора нет, вот и приходится везде это размазывать.
Здравствуйте, Serginio1, Вы писали:
S> Я это прекрасно понимаю. Но я обратил внимание на недостатки. S>Да для старого кода это киллер фича.
В первую очередь для нового — позволяет написать более продвинутый сервер для того же хттп. И в этом новом коде можно спокойно вызывать старый, и не бояться, что всё повалится.
Не нравится хттп — можете писать что угодно, ио или нет, не важно. И это будет эффективнее чем старыми приседаниями с потоками.
> Для тасков я так понимаю нет acync/await
С этой фичей нет нужды в async/await — все делается обычными вызовами функций.
P>Грубо говоря — по ссылкам утверждается, что весь IO поддерживается новой фичей, т.к. это наиболее сложная часть. Откуда следует, что новая фича только для ИО — не ясно, это ваша выдумка.
Грубо говоря нужно сказать, что IO и еще, что то. Но суть даже не в этом в .Net 90% асинхронщины это TaskCompletionSource c использованием CancellationToken
Поэтому сильно ограничен для использования в асинхронном коде, когда уже существую асинхронные аналоги
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Грубо говоря нужно сказать, что IO и еще, что то. Но суть даже не в этом в .Net 90% асинхронщины это TaskCompletionSource c использованием CancellationToken S>Поэтому сильно ограничен для использования в асинхронном коде, когда уже существую асинхронные аналоги
Не понял, джава виртуальные треды ограничены, потому что в дотнете есть асинхронные аналоги?
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>> Я тебе давал ссылку на твои слова. Ты сказал только об IO. ·>Приведи мои слова цитатой. С контекстом. И покажи где там "только".
То есть если ничего кроме IO не написал, значит "только" S>> Вот здесь товарищ привел все поддерживаемое http://rsdn.org/forum/philosophy/8525873.1
S>> Но и это по сути IO ·>Thread local vars это IO?!! Там из девяти пунктов ровно два про IO.
Каким боком Thread local vars если итак известно, что сохраняется весь стек. А
Thread local vars это часть стека https://habr.com/ru/articles/702814/
Там по понятием IO я имел ввиду I/O Completion Ports где система уже сама обеспечивает асинхронность.
Там единственно, что есть асинхронный wait по аналогии c SemaphoreSlim.WaitAsync
S>> ·>И здесь:
S>> ·>Ну и какой смысл в ограниченном IO? S>> Ограниченный в том, что нет TaskCompletionSource. ·>Ясно. Java IO ограничен тем, что в нём нет класса из c#. Невелика потеря. Или что ты сказать-то хотел?
S>> А это в реале 90% всех асинхронных методов ·>У _тебя_ в коде 90% вызовов асинхронных, поверю. Просто другого выбора нет, вот и приходится везде это размазывать.
90% используют TaskCompletionSource.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Pauel, Вы писали:
>> Для тасков я так понимаю нет acync/await
P>С этой фичей нет нужды в async/await — все делается обычными вызовами функций.
То есть ты не читатель? Нахрена я тут расписнаюсь про TaskCompletionSource и CancellationToken.
Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, Serginio1, Вы писали:
S>> Грубо говоря нужно сказать, что IO и еще, что то. Но суть даже не в этом в .Net 90% асинхронщины это TaskCompletionSource c использованием CancellationToken S>>Поэтому сильно ограничен для использования в асинхронном коде, когда уже существую асинхронные аналоги
P>Не понял, джава виртуальные треды ограничены, потому что в дотнете есть асинхронные аналоги?
Я так понимаю, что они в виртуальных потоках сделаны.
Но можно самому сделать эффективные. То есть у меня в руках намного больше инструментов для решения любых задач для асинхронного программирования.
Я очень рад за вас, что у вас появилась такая киллер фича!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> И заметь в том же Java существуют аналоги Task Future<T> or CompletableFuture<T> S> То есть их на свалку?
В 99% кода — да. И они должны жить только в 1% кода, где это _действительно_ нужно по дизайну. А не потому, что ОС не умеет слишком много потоков запускать. Ведь код пишется для того, чтобы человеки его читали, а не ОС или компилятор. Код должен быть простым насколько это возможно, но не проще.
Ты же заявил, что у тебя 90% кода на асинках. Зачем?
Здравствуйте, Serginio1, Вы писали:
S> Каким боком Thread local vars если итак известно, что сохраняется весь стек. А S> Thread local vars это часть стека https://habr.com/ru/articles/702814/
Нет. Они не часть стека. Под них выделяется память отдельно. О чём в этой статье и явно написано: "Выделить участок памяти по указанному в заголовку адресу".
Да не важно. Вопрос-то был — причём тут IO?
S> Там по понятием IO я имел ввиду I/O Completion Ports где система уже сама обеспечивает асинхронность.
Для сабжа не системма обеспечивать асинхронность, а jdk.
S> Там единственно, что есть асинхронный wait по аналогии c SemaphoreSlim.WaitAsync
IOCP — это только про windows. Никакого отношения к сабж не имеет.
S> 90% используют TaskCompletionSource.
Соболезную.
Здравствуйте, Serginio1, Вы писали:
>>> Для тасков я так понимаю нет acync/await
P>>С этой фичей нет нужды в async/await — все делается обычными вызовами функций.
S>То есть ты не читатель? Нахрена я тут расписнаюсь про TaskCompletionSource и CancellationToken.
Вся эта хрень работает и на виртуальных потоках.
S> И заметь в том же Java существуют аналоги Task Future<T> or CompletableFuture<T> S>То есть их на свалку?
Не в курсе подробностей реализации. Возможно, что они тоже поддерживаются новыми фичами.
S>>> Грубо говоря нужно сказать, что IO и еще, что то. Но суть даже не в этом в .Net 90% асинхронщины это TaskCompletionSource c использованием CancellationToken S>>>Поэтому сильно ограничен для использования в асинхронном коде, когда уже существую асинхронные аналоги
P>>Не понял, джава виртуальные треды ограничены, потому что в дотнете есть асинхронные механизмы?
S> Да уж!! То есть ты такой вывод оказывается сделал.
Это буквально следует из ваших слов. Кто чем в джаве ограничен — не ясно. С ваших слов вроде как джава ограничена дотнетом.
По ссылкам — лично я не вижу препятствий реализовать подобное и на виртуальных потоках. Может вы внятное что скажете, что именно почему нельзя реализовать в джаве? А то у вас общие слова, туманные мысли, и ссылки на паттерны и классы в дотнете.
S>Я так понимаю, что они в виртуальных потоках сделаны. S> Но можно самому сделать эффективные. То есть у меня в руках намного больше инструментов для решения любых задач для асинхронного программирования.
У вас, по большому счет, только async/await и отсутствие поддержки рантаймом. Все остальное более менее одинаково.
Во-первых, не "виртуальные потоки", а Fibers, они же "зеленые потоки", если управление ими осуществляется прозрачно некоей платформой/RTL/VM.
Какой двоечник придумал термин "виртуальные потоки" — это полный П. ))
Во-вторых, Fibers — это stackfull coroutines, а дотнетные таски — stackless coroutines.
С практической т.з. разница в том, что стековые корутины могут быть прерваны и продолжены на любой глубине вызова своего кода, а бесстековые могут прерываться и продолжаться только на верхнем уровне, где продолжение порой намного дороже предыдущего прерывания, т.к. необходимо осуществлять роутинг по состояниям вложенных автоматов, если логически код бесстековой корутины прерывался на вложенных своих вызовах.
Технически стековым корутинам выделяется стек и при их переключении происходит сохранение-загрузка регистров.
А бесстековая корутина — это детерминированный автомат (не обязательно конечный, но чаще конечный).
Грин треды решают общую проблему в программировании — вам не хочется, чтобы ваш код блокировал процессор, растрачивая ресурсы. Решается это использованием многозадачности, которая позволяет приостановить выполнение одного участка кода, запуская на выполнение другой, переключаясь между "контекстами".
Легко спутать с параллелизмом, но не делайте этого — это две совершенно разные вещи. Параллелизм — это как забрасывание проблемы вычислительными ресурсами. Грин треды позволяют работать умнее и эффективнее, эффективнее расходовать ресурсы.
У автора кукушка малость протекла, бессмысленный набор звуков. ))
Далее в статье рассуждения о вытесняющей или нет многозадачности — там тоже сплошная каша и непонимание.
И такого бреда в и-нете полно, почему-то.
"А на самом деле..." (С)
Всё проще, на самом деле.
"Обычные потоки вытесняющие" — не совсем.
Обычные треды тоже могут кооперативно передавать управление, в АПИ любой ОС есть соотв. ср-ва, например, SwitchToThread, pthread_yield.
"Зеленые потоки кооперативные" — не совсем.
Зеленый поток может быть вытеснен вместе со своим хостовым потоком уровня ОС.
Основная разница этих подходов в том, что потоки уровня ядра переключаются ядром и это дороже по двум всего причинам:
— переключение контекста текущего процесса, что дорого в ОС, работающих в защищённом режиме, т.е. с виртуальной памятью;
— ядро управляет очередью, где тусят все потоки всех процессов.
В случае зелёных/легких потоков, ситуация чуть другая:
— при их переключении не переключается контекст исполнения процессора/ядра, т.е. не переотображается виртуальная память (задержки переключения контекста именно тут);
— процесс занимается планировкой небольшой очереди легковесных потоков, в сравнении с ситуацией, где все процессы скидывали бы все свои тысячи уже нелёгких потоков в общую очередь.
Описанные трюки относятся не только к потокам, конечно, но и к таймерам, к примитивам синхронизации и т.д.
Например, дешевле иметь свою очередь таймеров уровня процесса если этих таймеров много, чтобы не засорять общую очередь таймеров уровня ядра.
Аналогично, если много семафоров.
Аналогично, если много сокетов — тогда на юзверский уровень вытаскивают из драйвера уровня ядра только сырые пакеты, а весь диспатчинг ожидающего на сокетах IO уже происходит на уровне юзверского процесса, с обыгрыванием высокоуровневых протоколов, типа TCP/UDP/IP.
Здравствуйте, Sinclair, Вы писали:
S>Вкратце, как я понимаю, основная проблема зелёных потоков — взаимодействие с неуправляемым кодом.
В дотнете та же фигня, обсуждали уже при обсуждении ReaderWriterLockSlim.
Получилась ужасно неэффективная реализация ReaderWriterLockSlim, как раз ввиду того, что объект может дёргаться как обычным образом, так и через async-методы.
Не зря я сразу по выходу говорил, что async/await в дотнете не нужен, его добавили туда не от большого ума.
Ведь в дотнете сразу сделали правильно — отделили "поток" дотнета от потока ОС и сразу же объявили, что 1:1 соответствие не гарантируется.
S>Java пытается выехать на том, что весь код — управляемый, и все блокирующие IO операции заботливо подменены под капотом на вызовы неблокирующих с последующим yield.
При чём тут "управляемый"?
Это можно делать и в неуправляемом коде — как в первых версиях Windows до 3.х включительно, или еще кучи других тогдашних многозадачных сред, типа Novell NetWare.
S>Если мы имеем несчастье вызвать какую-то IO библиотеку, которая написана до JDK 21, то виртуальный поток вполне успешно встанет в ожидание, сожрав поток ОС.
S>Но это — чисто performance issue, т.е. старый код продолжит работать так же, как он работал в старом JDK. Апгрейд на версию библиотеки, адаптированную к JDK 21, даст автоматическое улучшение масштабируемости приложения без переписывания кода.
Ничего не даст в плане IO, как ничего не дал async/await в сравнении с явной асинхронщиной на SocketAsyncEventArgs, даже хуже стало. ))
Просто эти async/await и соотв. новые методы понизили "планку входа", но не бесплатно — оно всё теперь работает заметно хуже, т.к. выше издержки.
Я ХЗ как ты упустил из виду то, что всем давно натёрло бельмо на глазу — есть фундаментальная проблема реализации зеленых потоков совместно с IO в современных ОС.
А именно — невозможно в одном АПИ ожидать готовность сокета и готовность мьютекса/семафора/события и т.д.
Например, под Windows это возможно частично — это надо привязать WSAEVENT к сокету, и такой HEVENT уже можно слушать готовность сокета через WaitForMultipleObjects вместе с семафорами и прочим, но там макс.кол-во хендлов 64, поэтому на этой основе "библиотеки широкого пользования" не пишут, из-за нулевой масштабируемости.
Плюс добавляется задержка на срабатывание HEVENT.
Который IOCP — там можно слушать сокеты, но нельзя мьютексы, семафоры.
Некоторые умельцы говорят, что слушают хендл IOCP через WaitForMultipleObjects, но фича недокументированная и ведёт себя по-разному в разных версиях Windows.
В Linux аналогично, полная задница ровно в этом же месте.
Есть костыли навроде eventfd, но они намного медленнее семафоров, плюс требуется порой переписывать почти всё в плане синхронизации, если до этого пользовались обычными примитивами синхронизации.
Поэтому, различные такие RTL языков с реализацией зеленых потоков или различные VM решают вопрос каждый в меру своей испорченности насчёт невозможности адекватного сосуществования пула потоков IO и пула потоков для зеленых потоков. Например, в дотнете это тупо два пула, и события часто передаются из пула в пул, что тормоза.
В других платформах, типа Go, Erlang — там ничего нельзя, кроме того, что дано изкаробки, что тоже не совсем адекватно в принятой в современном мире практики переиспользования уже имеющихся нейтивных библиотек на все случаи жизни. Как минимум где нужна малейшая синхронизация — их тянуть в Go и Erlang нельзя.
Собсно, поэтому эти языки никогда не выйдут из разряда "игрушечных", что в них тупо многое не работает.
Джава/дотнет в этом смысле позволяют разработчикам больше, но и цену платят дороже.
А, да, в Java NIO и NIO.2 всё по-уродски с IO-потоками, примерно как в дотнете.
S>Хуже — ситуация, когда мы вызываем какой-то неуправляемый код, который напрямую лезет в TLS средствами операционки. S>Приняты ли в JDK 21 какие-то меры борьбы с таким поведением?
В TLS лезть можно, если знать куда, к синхронизации никаким боком.
Я тут долго медитировал, что ты хотел сказать, но решил, что это просто несвежие грибы. ))
S>Если нет — то приложение просто взорвётся при переходе на виртуальные потоки.
В нейтиве к TLS привязывают обычно данные именно потока ОС, а не "логического".
И используют для того, чтобы не заниматься синхронизацией доступа к данным и чтобы улучшать локальность, т.е. это обычно системные какие-нить вещи, типа пула объектов, аллокаторы, связанный с данным физическим потоком диспетчер легковесных потоков/задач/IO и т.д.
Иначе, во время обработки сигналов в Linux или в completion routines в Windows можно такого наобрабатывать, если прикладную логику на TLS закладывать.
Например, через completion routines можно обслужить сколько угодно сокетов в одном потоке в асинхронном режиме.
Отличие от IOCP в том, что IO-операция привязана к одному потоку, а не к пулу их.
Именно поэтому completion routines работают намного эффективней IOCP. ))
Но в этой технике хуже с балансировкой нагрузки, ес-но.
S>В остальном — конечно, было бы прикольно иметь возможность прозрачного использования кооперативной многозадачности без утомительного переписывания прямолинейного кода на код с async/await.
А ведь говорилось сразу, что хернёй маются с этими async-await, что при наличии низлежащих либ фреймворка, с полным покрытием IO, эти задачи решаются иначе.
Просто пошли сначала по лёгкому пути, дав 1-в-1 отображение АПИ ОС на либы дотнета...
А затем, вместо того, чтобы переписать некую часть фреймворка, добавили сущностей.
Породили монструозный уродский Task.
Потом еще более уродский ValueTask, где на каждый чих по 3 проверки типа объекта в бестиповом поле object _obj.
А теперь всё, поезд ушел окончательно, как теперь от этого всего отказаться? ))
Здравствуйте, vdimas, Вы писали:
v> Кровь из ушей от названия.
v> https://en.wikipedia.org/wiki/Fiber_(computer_science) v> Понимаю, понимаю... v> Классам-то уже даны названия, производные от Thread? )) v> Поэтому, вертимся-крутимся ужиком... v> Детсад.
Ну потому что в API получилось так, что VirtualThread это потомок Thread и там где используется второе, можно подсунуть первое. С практической т.з. что работает для тредов, так же работает и для виртуальных тредов.
Более того, есть техническая возможность вытеснять виртуальные треды и возможно это даже появится в будущем.
"You can supply your own scheduler, written in Java, and you'll be able to choose to preempt a runaway thread. Currently, this capability is not exposed, but it will be eventually."
Здравствуйте, ·, Вы писали:
·>Ну потому что в API получилось так, что VirtualThread это потомок Thread и там где используется второе, можно подсунуть первое.
По-идее, в любой VM сущность Thread заведомо должна быть "виртуальной", как это сразу декларировалось для .Net, например, что не гарантируется привязка .Net-потока к потоку ОС.
И даже если дело в наследовании, ничего не мешало назвать общепринятым словом Fiber или LightweightThread.
GreenThread не пойдёт, т.к. этот термин используется обычно там, где легковесные потоки создаются и управляются некоей подсистемой автоматически, типа как в Erlang.
Обычных потоков там нет, а которые есть — зеленые.
Если бы дело было в начале нулевых, я бы к идентификаторам не придирался, но на сейчас сленг в этой области уже более-менее устаканился. ))
·>С практической т.з. что работает для тредов, так же работает и для виртуальных тредов.
Было бы лучше, чтобы все потоки стали легковесными, без ввода новой сущности.
Иначе в каждой блокирующей операции придётся делать лишнюю проверку относительно вида потока.
·>Более того, есть техническая возможность вытеснять виртуальные треды и возможно это даже появится в будущем. ·>"You can supply your own scheduler, written in Java, and you'll be able to choose to preempt a runaway thread. Currently, this capability is not exposed, but it will be eventually."
Разумеется, stackful-корутины могут вытесняться по прерываниям, т.к. технически они мало чем отличаются от потоков уровня ОС, отличаются только владельцем-шедуллером.
Разве что при вытеснении по прерываниям теряется легковесность переключения, т.к. вызовы проходят через ядро, т.е. получается профанация.
