·>В java уже virtual threads есть. По-моему, самое удобное.

И угадай, откуда там они появились, кто их писал, и откуда бралось вдохновение

Оно все равно не очень элегантно (из-за того, что shared memory модель из жабы не выкинешь), но уже почти там.

Здравствуйте, mrTwister, Вы писали:

T>·>Не очень понял в чём разница. Это называется вытесняющая многозадачность. ОС сама отпускает потоки, даже если там бесконечные циклы крутятся.
T>async/await — это и есть по сути попытка реализации кооперативной многозадачности в рамках ограниченного количества потоков ОС. В go эта многозадачность реализована более грамотно и она там действительно не кооперативная, а вытесняющая
Так ведь в Шарпе тоже вытесняющая, т.к. ОС вытесняет — циклы будут вытесняться, без всяких точек останова. Разница в блокировках на IO.

SD>>await разве умеет pattern matching?
Аё>Какая связь?

Я же привел пример.
await может ожидать получение КОНКРЕТНОГО результата. Тогда как receive + pattern matching — нескольких, причем выборочно. И записывается это с очень простым, понятным и читабельным синтаксисом. Это те самые "го с протоколами", только элегантно (хотя кому-то не хватает возможностей типа priority queue или multiple message queues).

Здравствуйте, ·, Вы писали:

·>Так ведь в Шарпе тоже вытесняющая, т.к. ОС вытесняет — циклы будут вытесняться, без всяких точек останова. Разница в блокировках на IO.

В рамках ограниченного числа потоков в тредпуле многозадачность кооперативная со степенью параллелизма равной размеру тредпула

Здравствуйте, SkyDance, Вы писали:

SD>·>В java уже virtual threads есть. По-моему, самое удобное.
SD>И угадай, откуда там они появились, кто их писал, и откуда бралось вдохновение
Kotlin и Go насколько я помню... Вот только VT реализовано по-человечески, обычные треды и синхронизация с т.з. пользователя, без всякого магического синтаксиса на уровне ЯП и прочие chan.

SD>Оно все равно не очень элегантно (из-за того, что shared memory модель из жабы не выкинешь), но уже почти там.
А её таки выкинули где-то? Это же объективная реальность.
В java можно и shared memory использовать, и каналы-сообщения, и locks, и lock-free и т.п. Что удобнее для данной задачи, то и выбираешь.

Здравствуйте, Артём, Вы писали:

Аё>...что не заняла жава, дополнил питон и нод ts.

Это у вас нагрузки слабые. Сколько ты в жабе можешь создать потоков в поде, допустим подам выделяется по 8 гиг оперативки? А сможешь в своей жабе сделать так, чтоб поток 2 кб весил? А открыть 50к соединений одновременно из этой поды сможешь открыть?
Можешь не отвечать. А, вот тебе ещё в догонку: сможешь сделать так, чтоб при указанных нагрузках не всё процессорное время сожрал GC?

Здравствуйте, mrTwister, Вы писали:

T>·>Так ведь в Шарпе тоже вытесняющая, т.к. ОС вытесняет — циклы будут вытесняться, без всяких точек останова. Разница в блокировках на IO.
T>В рамках ограниченного числа потоков в тредпуле многозадачность кооперативная со степенью параллелизма равной размеру тредпула
Это какое-то странное понимание. В таком случае какой-нибудь семафор или банальный rw-lock тоже можно назвать кооперативной многозадачностью — треды должны таки договариваться

Здравствуйте, Shmj, Вы писали:

S>Допустим, по умолчанию все функции сделать async, а компилятор уже сам оптимизирует.

Можно.
Windows 2.x-3.x работала именно так, причём, на нейтивных языках.


S>Понятно что для системных языков это не годится

Годится.
Это называется "кооперативная многозадачность".


S>Получается если не нужно ждать результата функции — пишем наоборот — nowait.

Если не нужно ждать результата ф-ии, т.е. вызывать шедуллер, то можно вызвать другую версию этой ф-ии — без ожидания.
Все "короткие" ф-ии именно таковы.
Шедуллер дергали только ф-ии IO.


S>Т.к. в основном асинхронных больше и даже если какая не асинхронная — то компилятор мог бы сам оптимизировать.

От компилятора тут ничего не требуется, если реализовать корутины в виде stackfull.

Здравствуйте, Shmj, Вы писали:

S>Допустим, по умолчанию все функции сделать async, а компилятор уже сам оптимизирует.
Если проектировать язык с нуля, то можно.

S>Понятно что для системных языков это не годится, но для бизнес-языков вполне.
Не очень понятно что вкладывается в понятие "системный язык".

S>Получается если не нужно ждать результата функции — пишем наоборот — nowait. Если ждать результат — ничего не пишем, по умолчанию.
Так работает Go

S>Т.к. в основном асинхронных больше и даже если какая не асинхронная — то компилятор мог бы сам оптимизировать.
Основная проблема в том, что асинхронность придется "прибивать" к рантайму, её нельзя будет сделать с помощью библиотеки, нельзя будет написать свой шедулер на этом языке и прочие радости.

Здравствуйте, Философ, Вы писали:

Ф>Это у вас нагрузки слабые. Сколько ты в жабе можешь создать потоков в поде, допустим подам выделяется по 8 гиг оперативки? А сможешь в своей жабе сделать так, чтоб поток 2 кб весил? А открыть 50к соединений одновременно из этой поды сможешь открыть?
Так есть же virtual threads.

Ф>Можешь не отвечать. А, вот тебе ещё в догонку: сможешь сделать так, чтоб при указанных нагрузках не всё процессорное время сожрал GC?
А причём тут сабж?

Здравствуйте, ·, Вы писали:

·>Это какое-то странное понимание. В таком случае какой-нибудь семафор или банальный rw-lock тоже можно назвать кооперативной многозадачностью — треды должны таки договариваться

Ну представь для простоты, что у тебя в пуле один поток. И мы используем один этот поток, чтобы конкурентно выполнять несколько кусков работы "процессов". Это можно сделать через async\await, разбив работу на таски и выстроив таски в цепочку. В этом случае получаем кооперативную многозадачность, так как таска должна добровольно отпустить поток, чтобы дать возможность конкурентному "процессу" продвинуться, выполнив свою таску. Тут стандартные проблемы: если таска ведет себя плохо, отказывается кооперироваться и не отдает поток, то все конкурентные процессы останавливаются.

Здравствуйте, mrTwister, Вы писали:


T>Ну представь для простоты, что у тебя в пуле один поток. И мы используем один этот поток, чтобы конкурентно выполнять несколько кусков работы "процессов". Это можно сделать через async\await, разбив работу на таски и выстроив таски в цепочку. В этом случае получаем кооперативную многозадачность, так как таска должна добровольно отпустить поток, чтобы дать возможность конкурентному "процессу" продвинуться, выполнив свою таску.
Это эквивалентно одному локу. Пока кто-то держит лок, другие ждут.

T>Тут стандартные проблемы: если таска ведет себя плохо, отказывается кооперироваться и не отдает поток, то все конкурентные процессы останавливаются.
Если таска ведёт себя плохо и не отпускает лок, то все конкурентные процессы останавливаются.

В чём разница-то?

Здравствуйте, ·, Вы писали:

·>Так есть же virtual threads.

И что, реально работает? Мне кажется с ними вылезает множество проблем с дедлоками. Я не спец по жабе, если что — просто задницей чувствую, что любой залётный дятел (объект синхронизации т.е.) способен принести кучу проблем, которых в гошке не бывает.


Ф>>Можешь не отвечать. А, вот тебе ещё в догонку: сможешь сделать так, чтоб при указанных нагрузках не всё процессорное время сожрал GC?
·>А причём тут сабж?

Чем больше потоков — тем больше рутов, от которых пляшет GC.

Здравствуйте, ·, Вы писали:

·>Здравствуйте, mrTwister, Вы писали:


T>>Ну представь для простоты, что у тебя в пуле один поток. И мы используем один этот поток, чтобы конкурентно выполнять несколько кусков работы "процессов". Это можно сделать через async\await, разбив работу на таски и выстроив таски в цепочку. В этом случае получаем кооперативную многозадачность, так как таска должна добровольно отпустить поток, чтобы дать возможность конкурентному "процессу" продвинуться, выполнив свою таску.
·>Это эквивалентно одному локу. Пока кто-то держит лок, другие ждут.

T>>Тут стандартные проблемы: если таска ведет себя плохо, отказывается кооперироваться и не отдает поток, то все конкурентные процессы останавливаются.
·>Если таска ведёт себя плохо и не отпускает лок, то все конкурентные процессы останавливаются.

·>В чём разница-то?

Мьютекс сам по себе не позволит тебе конкурентно выполнять несколько "просессов" на одном потоке. Тебе нужно разбивать "процессы" на подзадачи, строить цепочки таскок и переключаться между ними.

Здравствуйте, Философ, Вы писали:

Ф>·>Так есть же virtual threads.
Ф>И что, реально работает? Мне кажется с ними вылезает множество проблем с дедлоками. Я не спец по жабе, если что — просто задницей чувствую, что любой залётный дятел (объект синхронизации т.е.) способен принести кучу проблем, которых в гошке не бывает.
Работет, что такого невозможного? Дедлоки тут причём? Если лочишь, то и в гошке будут проблемы. В гошке те же структуры и примитивы синхронизации. Просто channels там встроены в синтаксис и штука по умолчанию, тогда как в java там можно выбирать что угодно.

Ф>>>Можешь не отвечать. А, вот тебе ещё в догонку: сможешь сделать так, чтоб при указанных нагрузках не всё процессорное время сожрал GC?
Ф>·>А причём тут сабж?
Ф>Чем больше потоков — тем больше рутов, от которых пляшет GC.
Не совсем рутов, а стеки в VT это просто ноды в куче для GC. И async-таски — те же ноды, только через Ж.

Здравствуйте, mrTwister, Вы писали:

T>·>Если таска ведёт себя плохо и не отпускает лок, то все конкурентные процессы останавливаются.
T>·>В чём разница-то?

T>Мьютекс сам по себе не позволит тебе конкурентно выполнять несколько "просессов" на одном потоке. Тебе нужно разбивать "процессы" на подзадачи, строить цепочки таскок и переключаться между ними.
Это понятно что модели как пишется код, конечно, разные. Но корректно продуманная кооперация требуется ровно так же.

Здравствуйте, Shmj, Вы писали:

S>Т.к. в основном асинхронных больше и даже если какая не асинхронная — то компилятор мог бы сам оптимизировать.

Наоборот синхронных методов больше. Асинхронщина это обычно либо IO или выделение долгих методов в отдельный поток, что бы не тормозить UI через Task.Run

Здравствуйте, gandjustas, Вы писали:

S>>Получается если не нужно ждать результата функции — пишем наоборот — nowait. Если ждать результат — ничего не пишем, по умолчанию.
G>Так работает Go

Проверял или просто веришь?

Вот C#

async Task<int> SumAsync(int a, int b) {
    return a + b;
}

var x = await SumAsync(2, 3);

Эквивалент в Go

func sumAsync(a, b int) <-chan int {
    ch := make(chan int, 1)

    go func() {
        ch <- a + b
        close(ch)
    }()

    return ch
}

x := <-sumAsync(2, 3)

— еще хуже.

Здравствуйте, Serginio1, Вы писали:

S>Наоборот синхронных методов больше. Асинхронщина это обычно либо IO или выделение долгих методов в отдельный поток, что бы не тормозить UI через Task.Run

Так бизнес- приложение только и делает что берет из базы, берет из сети и что-то там комбинирует — а это все асинхрон.

Здравствуйте, Shmj, Вы писали:

S>>Наоборот синхронных методов больше. Асинхронщина это обычно либо IO или выделение долгих методов в отдельный поток, что бы не тормозить UI через Task.Run

S>Так бизнес- приложение только и делает что берет из базы, берет из сети и что-то там комбинирует — а это все асинхрон.
Угу и вся логика на сервере, клиент только получает результат. Но в реальности это не так.

Хотя возможно для таких приложений нужен свой язык. Здесь уже будет зависеть от необходимости. Пока такой необходимости нет.
А вызов без await подсвечивается в редакторе.