Здравствуйте, ·, Вы писали:
·>Можно писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код. ·>Кооперативная многозадачность. Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.
Здравствуйте, SkyDance, Вы писали:
Pzz>>А в гошечке не только preemption есть, но еще и компиляция в машинный код.
SD>В Erlang'е тоже. Причем сначала было именно как "компиляция" (HiPE), потом сделали нормальный JIT/AOT (и грохнули неудобный HiPE).
Ерланг же динамически типизован. Разве в динамически типизованном языке возможна генерация эффективного кода?
Pzz>Ерланг же динамически типизован. Разве в динамически типизованном языке возможна генерация эффективного кода?
Там строгая система типов. Конструкции типа 2 + "string" являются ошибочными. И вообще, динамическая типизация — свойство компиляторе, в AOT есть часть загрузчика байт-кода.
Конкретно Erlang решает эту задачу путем внедрения compiler type information в байт-код. Тут здорово помогает тот факт, что все переменные иммутабельны, и их тип может быть выведен заранее на этапе компиляции.
PS: обрати внимание на dialyzer. Он вообще все типы выводит статически.
Здравствуйте, Pzz, Вы писали:
Pzz>В яву завезли goroutines?
Нет, это невытесняющая многозадачность, реализованная на уровне JVM. Когда код вызывает любую блокирующую операцию (wait/sleep/synchronized/blocking io), управление передается в джавовый планировщик, который сохранит текущий стек и запустит на выполнение какой-нибудь другой кусок кода с сохраненным стеком.
Здравствуйте, Pzz, Вы писали:
Pzz> В яву завезли goroutines?
Нет, такого добра уже везде как грязи. Горутины это специальная модель асинхронного взаимодействия — где у тебя есть специально помеченный в ЯП кусок кода и определённый механизм взаимодействия — каналы и посылка сообщений, тоже со своими ключевыми словами в ЯП и специальным магическим синтаксисом. И оно никак не стыкуется с классическими механизмами типа локов, хотя они тоже есть в go.
Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами.
Здравствуйте, ·, Вы писали:
·>Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами.
Каким образом джава узнает, что вон тот метод у нас работает долго и при его вызове надо бы перешедулить?
Здравствуйте, ·, Вы писали:
·>В сентябре обещают зарелизить JEP 444
·>Можно писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код. ·>Кооперативная многозадачность. Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.
Можно. Судя по тому, что джава-девелоперы до сих пор удивляются лямбдам и сидят на джава 1.8, эта фича в массы дойдет лет через 10, а к тому времени её возьмут и выбросят, как это было с зелеными потоками.
Здравствуйте, Pauel, Вы писали:
P>·>Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами. P>Каким образом джава узнает, что вон тот метод у нас работает долго и при его вызове надо бы перешедулить?
Тут уже отвечали.
Помимо обычных блокировок в виде локов, они ещё переработали синхронное IO, например. Т.е. тупой линейный код как в go socket.readAllBytes(); ... socket.write(response);, тред для каждого клиента и внутре случается магия всяких epoll, виртуальный тред на блокирующем io так же перешедуливается.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Pauel, Вы писали:
P>·>Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами.
P>Каким образом джава узнает, что вон тот метод у нас работает долго и при его вызове надо бы перешедулить?
Насколько я понимаю — никаким. Вечный цикл займёт тред навсегда. И если треды кончатся, то всё встанет колом (в отличие от настоящих потоков).
Здравствуйте, vsb, Вы писали:
P>>Каким образом джава узнает, что вон тот метод у нас работает долго и при его вызове надо бы перешедулить? vsb>Насколько я понимаю — никаким. Вечный цикл займёт тред навсегда. И если треды кончатся, то всё встанет колом (в отличие от настоящих потоков).
Тут немного не так. Точнее совсем не так.
Если бесконечный цикл — ошибка в коде, то виртуальный тред займёт настоящий и никакому другому виртуальному треду больше не отдаст, будет жрать cpu. По сути виртуальный тред как бы выродится в настоящий. Т.е. это утечка ресурса.
Если это просто некий временный load burst и большое число виртуальных тредов начнёт чего-то усердно считать, то они начнут захапывать реальные треды из пула. И там уже от настроек пула зависит. Например, пул может пытаться неограниченно создавать новые реальные треды пока память не закончится или ОС не начнёт протестовать. По дефолту пул, вроде, ограничивается числом ядер в cpu.
Т.е. всё как настоящие потоки получается. Плохая кооперация виртуальных тредов тупо вырождает их в настоящие. Единственное, что пропадает fairness — те виртуальные треды которые захапали все настоящие, то остальным виртуальным тредам ничего не достанется, пока те не начнут отдавать захапанное.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Нет, такого добра уже везде как грязи. Горутины это специальная модель асинхронного взаимодействия — где у тебя есть специально помеченный в ЯП кусок кода и определённый механизм взаимодействия — каналы и посылка сообщений, тоже со своими ключевыми словами в ЯП и специальным магическим синтаксисом. И оно никак не стыкуется с классическими механизмами типа локов, хотя они тоже есть в go.
В каком смысле, не состыкуются. В go есть локи, а есть каналы. Что хочешь, то и пользуй. То, что там есть специальный синтаксис для запуска потока разве чего-то меняет?
Здравствуйте, Pauel, Вы писали:
P> Можно. Судя по тому, что джава-девелоперы до сих пор удивляются лямбдам и сидят на джава 1.8,
Ну на 1.8 сидят далеко не все, обычно те, у которых очень много легаси кода. Но, как мне кажется, сабж может быть хорошим преимуществом — запускать древний синхронный тормозной код асинхронно. Т.е. взять старый код с бизнес логикой, которая ходит синхронно туда-сюда в базу, в файлы, в SOAP и т.п, и замасштабировать на тысячи тредов, без пенальти от ОС.
А я что-то не припомню фич между 1.8 и JDK 20 которые как-то могут улучшить работу и использование старого кода, обычно только упрощения для написания нового. Ну может какие-то новые алгоритмы GC... дополнительные всяческие оптимизации, да и наверное всё.
P> эта фича в массы дойдет лет через 10, а к тому времени её возьмут и выбросят, как это было с зелеными потоками.
По-моему зелёные потоки были по сути затычкой к ОС-тредам в то время, когда среди ОС реализация тредов была большим разбродом и шатанием, да и многопроцессорные системы были редкостью.
Когда большинство ОС стали более менее вменяемо уметь в треды, то их и выкинули, тупо за ненадобностью.
Сейчас же стал популярен асинхронный код, для которого и сделали сабж.
Здравствуйте, Pzz, Вы писали:
Pzz> ·>Нет, такого добра уже везде как грязи. Горутины это специальная модель асинхронного взаимодействия — где у тебя есть специально помеченный в ЯП кусок кода и определённый механизм взаимодействия — каналы и посылка сообщений, тоже со своими ключевыми словами в ЯП и специальным магическим синтаксисом. И оно никак не стыкуется с классическими механизмами типа локов, хотя они тоже есть в go. Pzz> В каком смысле, не состыкуются. В go есть локи, а есть каналы. Что хочешь, то и пользуй. То, что там есть специальный синтаксис для запуска потока разве чего-то меняет?
В принципе да, для go это немного другое, т.к. там аналога VM нет. Java это платформа, там крутятся много языков. Если бы сабж реализовали как спец-синтаксис в ЯП — было бы жуть.
A>·>Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.
A>Получается автоматическая асинхроность без всякого переписывания кода. Умно, ждем в .NET такое.
Ну как не переписывать: нужно как минимум создать экземпляр VirtualThread и запихнуть туда лямбду с кодом (а если ещё вспомнить, что лямбды в Java не умеют захватывать неконстантные переменные в отличие от C#)
Из статьи на которую ссылается TC, преимущество перед async/await неочевидно (там сравнение с async/await в Котлине)
(https://blog.rockthejvm.com/ultimate-guide-to-java-virtual-threads/)
·>Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами.
Погодите, а как же cancellation?
Вот в C# например я не могу использовать обычную lock секцию с async/await и вместо этого вынужден делать крит. секцию на основе SemaphoreSlim, где есть асинхронный wait и Cancellation.
Здравствуйте, m2user, Вы писали:
m> ·>Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами. m> Погодите, а как же cancellation?
Банальный interrupt() например, доступный ещё с java 1.0.
Ну или Future.cancel() или любой другой паттерн.
Просто представь себе как бы ты писал простой, читабельный код, если ты знаешь, что там будет максимум десяток тредов. И представь себе, что этот код потом можно отмасштабировать на миллионы.
m> Вот в C# например я не могу использовать обычную lock секцию с async/await и вместо этого вынужден делать крит. секцию на основе SemaphoreSlim, где есть асинхронный wait и Cancellation.
Именно. Вот об этом гне и говорю. Есть Wait, и ещё нужен AsyncWait и ещё с CancellationToken . Итого намножилось аж 12 методов. И это приходится размазывать повсюду.
. Итого намножилось аж 12 методов. И это приходится размазывать повсюду.
