Сообщение Re[4]: Киллер фича JDK 21 - virtual threads от 09.05.2023 22:01
Изменено 09.05.2023 22:03 ·
Re[4]: Киллер фича JDK 21 - virtual threads
Здравствуйте, m2user, Вы писали:
m> ·>Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами.
m> Погодите, а как же cancellation?
Банальный interrupt() например, доступный ещё с java 1.0.
Ну или Future.cancel() или любой другой паттерн.
Просто представь себе как бы ты писал простой, читабельный код, если ты знаешь, что там будет максимум десяток тредов. И представь себе, что этот код потом можно отмасштабировать на миллионы.
m> Вот в C# например я не могу использовать обычную lock секцию с async/await и вместо этого вынужден делать крит. секцию на основе SemaphoreSlim, где есть асинхронный wait и Cancellation.
Именно. Вот об этом гне и говорю. Есть Wait, и ещё нужен AsyncWait и ещё один AsyncWait с CancellationToken
. Итого намножилось аж 12 методов. И это приходится размазывать повсюду.
m> ·>Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами.
m> Погодите, а как же cancellation?
Банальный interrupt() например, доступный ещё с java 1.0.
Ну или Future.cancel() или любой другой паттерн.
Просто представь себе как бы ты писал простой, читабельный код, если ты знаешь, что там будет максимум десяток тредов. И представь себе, что этот код потом можно отмасштабировать на миллионы.
m> Вот в C# например я не могу использовать обычную lock секцию с async/await и вместо этого вынужден делать крит. секцию на основе SemaphoreSlim, где есть асинхронный wait и Cancellation.
Именно. Вот об этом гне и говорю. Есть Wait, и ещё нужен AsyncWait и ещё один AsyncWait с CancellationToken
. Итого намножилось аж 12 методов. И это приходится размазывать повсюду.Re[4]: Киллер фича JDK 21 - virtual threads
Здравствуйте, m2user, Вы писали:
m> ·>Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами.
m> Погодите, а как же cancellation?
Банальный interrupt() например, доступный ещё с java 1.0.
Ну или Future.cancel() или любой другой паттерн.
Просто представь себе как бы ты писал простой, читабельный код, если ты знаешь, что там будет максимум десяток тредов. И представь себе, что этот код потом можно отмасштабировать на миллионы.
m> Вот в C# например я не могу использовать обычную lock секцию с async/await и вместо этого вынужден делать крит. секцию на основе SemaphoreSlim, где есть асинхронный wait и Cancellation.
Именно. Вот об этом гне и говорю. Есть Wait, и ещё нужен AsyncWait и ещё с CancellationToken. Итого намножилось аж 12 методов. И это приходится размазывать повсюду.
m> ·>Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами.
m> Погодите, а как же cancellation?
Банальный interrupt() например, доступный ещё с java 1.0.
Ну или Future.cancel() или любой другой паттерн.
Просто представь себе как бы ты писал простой, читабельный код, если ты знаешь, что там будет максимум десяток тредов. И представь себе, что этот код потом можно отмасштабировать на миллионы.
m> Вот в C# например я не могу использовать обычную lock секцию с async/await и вместо этого вынужден делать крит. секцию на основе SemaphoreSlim, где есть асинхронный wait и Cancellation.
Именно. Вот об этом гне и говорю. Есть Wait, и ещё нужен AsyncWait и ещё с CancellationToken
. Итого намножилось аж 12 методов. И это приходится размазывать повсюду.