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

I>И по твоему Thread.Sleep асинхронный ? Да ты, я вижу, непростой
I>Замени его на Таймер, что бы получить асинхронность и объясни результаты.

Ничего не понял.

НС>>Не нужен, таски прекрасно работают и в консольных приложениях. Нужен для синхронизации в случае GUI.
I>Ога. Это если ты Thread.Sleep вызываешь.

Это неважно что ты вызываешь. Любая CPU bound задача будет вести себя аналогично. И колбеки IOCP тоже будут порождаться в других потоках.

НС>>Смысл фразы непонятен.
I>Я заметил это по Thread.Sleep

А по русски повторить не можешь?

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

N> То есть всё это не более чем пул нитей с каким-то хилым закосом под человеческую морду.

Нет. Это вообще не про пул нитей.

N>Но косвенным подтверждением является то, что статья в MSDN Magazine разливается соловьём про разные вычисления (CPU-bound) и ни слова про ввод-вывод

С IO bound там тоже все хорошо.

N>однозначный расчёт на потенциально долгое выполнение одной задачи.

С точностью до наоборот — таски заточены под fine grained паралллелизм, т.е. под много коротких задач.

N>Там, где на IOCP и аналогах можно зашедулить пару тысяч одновременных I/O операций, тут ты это не сделаешь в принципе.

Ты точно ничего не понял. Таски это не замена IOCP и для ввода-вывода этот самый IOCP в тасках используется напрямую.

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

НС>>Да не переключает в тасках никто выполнение нитей. Совсем. Пока конкретная таска выполняется, она владеет потоком ОС монопольно.
I>А эвентлуп каким то чудом узнает, что вон тот колбек он идет от этого таска, а не от того

Эвентлуп вообще ничего не узнает. Он используется только для отдачи результатов в основной поток при соответствующем контексте.

I>>>Если бы в С# был экспрешном и работал как yield в Питоне
НС>>Переведи на русский.
I>Здесь все просто
I>var x = yield(Task.SomeAwaitable())
I>получается тот же await

Стало еще меньше понятно о чем ты хотел сказать.

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

I>Как и зеленый поток, вообще говоря Выполнение ты сам переключаешь. Например, так —
I>

I>var x = await Something(...)
I>

I>await отдаёт управление шедулеру, а он сам решит, чего и когда продолжить.

Ты по прежнему путаешь таски и реализацию continuation monad в компиляторе C#.

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

N>По тому, что я вижу на СУБД, они делают сессии целыми нитями или даже процессами (под Unix, где это относительно дёшево).

Кто они? Касательно MSSQL, к примеру, IOCP прекрасно можно использовать — SqlCommand.ExecuteReaderAsync использует в конечном итоге IOCP на сокет сервера, то есть никаких потоков во время ожидания в пуле не блокируется.

Здравствуйте, Ночной Смотрящий, Вы писали:

N>> То есть всё это не более чем пул нитей с каким-то хилым закосом под человеческую морду.
НС>Нет. Это вообще не про пул нитей.

Естественно, это не "про" пул нитей. Но внутри это пул нитей, о чём статья явно говорит.

N>>Но косвенным подтверждением является то, что статья в MSDN Magazine разливается соловьём про разные вычисления (CPU-bound) и ни слова про ввод-вывод
НС>С IO bound там тоже все хорошо.

Объясни, как именно. Из указанных тобой ресурсов это не следует, скорее наоборот.

N>>однозначный расчёт на потенциально долгое выполнение одной задачи.
НС>С точностью до наоборот — таски заточены под fine grained паралллелизм, т.е. под много коротких задач.

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

N>>Там, где на IOCP и аналогах можно зашедулить пару тысяч одновременных I/O операций, тут ты это не сделаешь в принципе.
НС>Ты точно ничего не понял. Таски это не замена IOCP и для ввода-вывода этот самый IOCP в тасках используется напрямую.

Каким именно образом? "Таска" ставится без условий запустить её только если выполнилось какое-то внешнее условие, а возможности дешёвого ожидания в уже работающей задаче ты не показал.

Здравствуйте, Ночной Смотрящий, Вы писали:

N>>По тому, что я вижу на СУБД, они делают сессии целыми нитями или даже процессами (под Unix, где это относительно дёшево).
НС>Кто они?

mysql, postgresql, firebird.
СУБД без открытого кода движка я тут не рассматриваю по определению.

НС> Касательно MSSQL, к примеру, IOCP прекрасно можно использовать — SqlCommand.ExecuteReaderAsync использует в конечном итоге IOCP на сокет сервера, то есть никаких потоков во время ожидания в пуле не блокируется.

Это в T-SQL? Если да, то это уже не в счёт.

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

S>>>Можешь объяснить, при чём тут вообще кооперативная многозадачность и какой магией зелёные потоки будут отличаться от тасков?
I>>Если в одном потоке всякие IOCP, BeginXXX, EndXXX, то асинхронщина здесь и есть та самая кооперативная многозадачность.
S>Нет. Хотя бы потому, что IOCP и "в одном потоке" не соотносятся вообще никак, почитай как оно работают.

На MSDN описано лучше.

S> Запрос инициируется с рабочего потока, запихивается в очередь iocp, по завершению — продолжает выполнение в потоке из IOCP-пула. Кооперативной многозадачности тут нет: обработчики iocp будут выполняться параллельно вплоть до исчерпания пула потоков.

Не-а. Всё описанное тобой получается только в случае если ты сам, явно, определишь какой-то "пул" ниток, которые не будут делать ничего кроме как дёргать GetQueuedCompletionStatus(); но это будет _твоё_, как разработчика, решение. В то же время, если ты сделаешь в одной нити

создание IOCP

создание и связь с этим IOCP некоторых начальных генераторов событий, типа слушающего сокета

цикл типа "пока не приказали посинеть" из ожидания события и его обработки, включая помещение новых асинхронных операций с оповещением через тот же IOCP объект

у тебя получится ровно то, что говорит Ikemefula: "асинхронщина" через кооперативную многозадачность собственного исполнения. При этом ничто не мешает сделать несколько таких нитей и распределить работу между ними (например, раскидывая входящие соединения), каждую привязывать к своему IOCP.

А если не ограничиваться одной нитью, то всё равно получается "асинхронщина", но уже с усложнением (синхронизация доступа к общим ресурсам и т.п.)

S>Это всё упрощённо и очень схематично конечно, реализации могут быть разные. Но варианта "асинхронщина здесь и есть та самая кооперативная многозадачность" точно не будет. За бесполезностью

Он очень даже полезен, и во многих случаях более того стиля общения с IOCP, который ты пропагандируешь.

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

N>>Картинку видел. Но там нет никаких прямых данных о делении по "миру разработки". А косвенно, если пересчитать, мои данные ничуть этому не противоречат, если, например, в коробочном ПО C/C++ занимает процентов 90, а во внутреннем — 30 (а ява, например, 50), то в сумме получатся где-то те же цифры.
_>Да, в принципе такое возможно. Правда в таком случае мир коробочного ПО уж совсем мелкий должен быть, потому как в данных рассуждениях был забыт (кстати про него почему-то часто забывают тут) embedded мир. Который весьма не маленький и как раз в нём основное царство C, с вкраплениями asm и C++.

Embedded широк по количеству установок, но узок — по количеству людей, которые в нём работают. Тем более что сейчас всё больше такого embedded, где линукс запускается без особых тормозов...

_> Так что цифра в 70-80% программистов мира работающих на внутреннее ПО мне кажется всё же несколько завышенной. Хотя всё может быть, у меня нет прямых цифр на этот счёт.

Я тот источник тоже не могу найти, картина могла, конечно, сдвинуться существенно. Вообще сейчас деление по языкам в нём потеряло важность (PHP+JS это где? Это может быть и в домашнем раутере)

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

N>Естественно, это не "про" пул нитей. Но внутри это пул нитей, о чём статья явно говорит.

Внутри может быть что угодно, читай внимательнее этот топик.

N>Объясни, как именно.

Что значит как именно? Когда я создаю таски, завязанные на ввод-вывод, используются абсолютно стандартные IOCP.

НС>>С точностью до наоборот — таски заточены под fine grained паралллелизм, т.е. под много коротких задач.
N>Не смешивай расчёт на идеальное применение

Это не идеальное применение, это design target при создании тасков.

НС>>Ты точно ничего не понял. Таски это не замена IOCP и для ввода-вывода этот самый IOCP в тасках используется напрямую.
N>Каким именно образом?

Вопрос непонятен.

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

А как я ее должен показать, интересно?

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

N>mysql, postgresql, firebird.

Без понятия.

N>СУБД без открытого кода движка я тут не рассматриваю по определению.

Смешно.

Здравствуйте, Ночной Смотрящий, Вы писали:

N>>Естественно, это не "про" пул нитей. Но внутри это пул нитей, о чём статья явно говорит.
НС>Внутри может быть что угодно, читай внимательнее этот топик.

Почему я должен верить "этому топику" и не верить статье в MSDN Magazine?

N>> "Таска" ставится без условий запустить её только если выполнилось какое-то внешнее условие, а возможности дешёвого ожидания в уже работающей задаче ты не показал.
НС>А как я ее должен показать, интересно?

Сделай следующий эксперимент. Поставь на выполнение в самом начале работы программы N задач, каждая из которых

фиксирует время начала выполнения рабочей функции

делает sleep(M секунд)

фиксирует время конца выполнения рабочей функции и возвращает результат — сколько прошло с момента старта (в секундах)

и, когда они все закончат выполняться, собери распределение ответов как минимум по децилям, среднее по каждому квантилю. У меня следующие предположения о том, как это будет работать:

Вариант 1. Задачи в спячке запустятся по количеству логических процессоров (далее nLR), и займут всё. В таком случае выполнение займёт до нескольких суток, максимальное возвращаемое значение будет около 1000000/nLR и график значений будет похоже на линейную функцию.

Вариант 2. Кто-то по дороге до системного Sleep() перехватит факт блокирующего вызова и вызовет переключение на исполнение другой задачи. В таком случае все значения будут близки к 100. Это будет означать, что фактически он работает поверх зелёных нитей.

Вариант 3. Пул, заметив, что все нити заняты, а задач в очереди ещё дофига, начнёт создавать новые нити и скидывать задачи на них. В зависимости от того, сколько в пределе он может позволить себе создать, среднее будет менее 1000000/nLR, но более 100. Далее можно будет оценить методы его работы. Например, если детект переполнения периодический, раз в секунду, а предельное количество нитей не ограничено, то среднее будет порядка 500000/nLR, а средние по квантилям покажут ровную лесенку.

Начинать с N=100, M=10, и увеличивать пока принципиальная картина не перестанет меняться.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, netch80, Вы писали:

N>>mysql, postgresql, firebird.

НС>Без понятия.

N>>СУБД без открытого кода движка я тут не рассматриваю по определению.

НС>Смешно.

Я говорил о коде собственно СУБД (а не пользовательском в нём), и думаю, ты его не можешь увидеть тоже. Поэтому нет причин для смеха.

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

N>Почему я должен верить "этому топику" и не верить статье в MSDN Magazine?

Потому что статья просто не раскрывает тему.

НС>>А как я ее должен показать, интересно?
N>Сделай следующий эксперимент. Поставь на выполнение в самом начале работы программы N задач, каждая из которых
N>

фиксирует время начала выполнения рабочей функции
N>

делает sleep(M секунд)
N>

фиксирует время конца выполнения рабочей функции и возвращает результат — сколько прошло с момента старта (в секундах)

И где здесь IOCP? CPU bound в чистом виде.

N>Вариант 2. Кто-то по дороге до системного Sleep() перехватит факт блокирующего вызова и вызовет переключение на исполнение другой задачи.

Не перехватит. Еще раз — таски это не зеленые потоки, никакой магии по прерыванию нити вне механики ОС в них нет, не стоит путать таски с continuation monad в шарпе. Если у тебя CPU bound задача, то она будет выполнятся в рамках тасков точно так же, как и при ручном забирании потока из пула. Если же тебе нужно притормозить таску не занимая поток — есть Task.Delay(), внутри которого, внезапно, IOCP на системном таймере.
Если же пытаться специально обмануть фремворк так, чтобы поставить его раком — это всегда можно сделать, безусловно.

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

N>Я говорил о коде собственно СУБД (а не пользовательском в нём), и думаю, ты его не можешь увидеть тоже. Поэтому нет причин для смеха.

Когда в руках молоток — все вокруг кажется гвоздями.

Здравствуйте, Ночной Смотрящий, Вы писали:

N>>Почему я должен верить "этому топику" и не верить статье в MSDN Magazine?
НС>Потому что статья просто не раскрывает тему.

Судя по твоему же ответу ниже, она достаточно её раскрывает, применительно к теме данного обсуждения.

НС>>>А как я ее должен показать, интересно?
N>>Сделай следующий эксперимент. Поставь на выполнение в самом начале работы программы N задач, каждая из которых
N>>

фиксирует время начала выполнения рабочей функции
N>>

делает sleep(M секунд)
N>>

фиксирует время конца выполнения рабочей функции и возвращает результат — сколько прошло с момента старта (в секундах)
НС>И где здесь IOCP? CPU bound в чистом виде.

IOCP тут, действительно, ни при чём. А вот называть sleep(), который превращается в перевод треда в спящее состояние и ожидание прерывания от таймера (через прокладку в виде диспетчера), "CPU bound", это верх запутывания. Это чистое IO, и эффект от него такой же, как если бы задача сделала блокирующий read().

N>>Вариант 2. Кто-то по дороге до системного Sleep() перехватит факт блокирующего вызова и вызовет переключение на исполнение другой задачи.

НС>Не перехватит. Еще раз — таски это не зеленые потоки, никакой магии по прерыванию нити вне механики ОС в них нет,

Во! Это то, что я ожидал от тебя в данном треде. А теперь, возвращаясь на K сообщений назад:

НС>>>Не знаю что у тебя там возникает, но таски прекрасно справляются без кооперативной многозадачности.

эта реплика становится неадекватной, потому что "таски" не могут справляться без кооперативной задачности любого вида с ситуацией заказа многих ожиданий.

НС> не стоит путать таски с continuation monad в шарпе.

Я не путаю, потому что последнего просто не знаю Ну нету у меня шарпа в работе.

НС> Если у тебя CPU bound задача, то она будет выполнятся в рамках тасков точно так же, как и при ручном забирании потока из пула. Если же тебе нужно притормозить таску не занимая поток — есть Task.Delay(), внутри которого, внезапно, IOCP на системном таймере.
НС>Если же пытаться специально обмануть фремворк так, чтобы поставить его раком — это всегда можно сделать, безусловно.

Ты вцепился в sleep как финальную однозначность, поэтому вспоминаешь про Delay(). Хорошо, представим себе вместо этого чтение чего-то, что придёт в дескриптор только через минуту. Результат тот же (и см. выше про IO bound).

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

N>IOCP тут, действительно, ни при чём. А вот называть sleep(), который превращается в перевод треда в спящее состояние и ожидание прерывания от таймера (через прокладку в виде диспетчера), "CPU bound", это верх запутывания.

С точки зрения тасков это CPU bound. Таски это не низкоуровневый механизм ядра, это прикладная библиотека высокого уровня. Зачем ты пытаешься навесить на нее абсолютно несвойственный ей функционал — мне непонятно.

N> Это чистое IO, и эффект от него такой же, как если бы задача сделала блокирующий read().

Ну так не надо делать блокирующий read.

НС>>Не перехватит. Еще раз — таски это не зеленые потоки, никакой магии по прерыванию нити вне механики ОС в них нет,
N>Во! Это то, что я ожидал от тебя в данном треде.

Я это пишу здесь ровно с первого сообщения.

НС>>>>Не знаю что у тебя там возникает, но таски прекрасно справляются без кооперативной многозадачности.
N>эта реплика становится неадекватной, потому что "таски" не могут справляться без кооперативной задачности любого вида с ситуацией заказа многих ожиданий.

Никто и не обещал что они будут справляться вообще со всем (кроме, разве, Икемефулы). Они решают вполне определенный, пусть и довольно широкий круг задач, и решают его хорошо. И обходятся при этом без зеленых потоков.

НС>> не стоит путать таски с continuation monad в шарпе.
N>Я не путаю, потому что последнего просто не знаю Ну нету у меня шарпа в работе.

Это на случай если ты принимаешь на веру то, что тут пишет Икемефула. Потому что на самом деле есть 2 сущности:
1) TPL ака таски. Это библиотека, которая появилась задолго до шарповских async/await, в 4 фреймворке. Цель ее создания — облегчение написания асинхронного fine grained кода. Первая версия создавалась прежде всего для внутреннего слоя PLINQ — декларативного использования асинхронности на задачах обработки последовательностей. Потом таски стали использовать в Reactive Extensions, потом в ASP.NET MVC. Это все еще до C# 5, который с поддержкой асинхронности.
2) async/await в C# 5+. Это вшитая в язык continuation monad. Если очень грубо, то компилятор разрезает линейный как бы синхронный исходный код по явно указанным точкам на куски, выстраивая зависимости между ними. А затем, на основании этой информации, создает FSM, который позволяет выполнять эти куски по отдельности (логика примерно та же, что и при реализации yield для итераторов). Соответственно, визуально это выглядит как будто кто то "прерывает" выполнение синхронного кода, но на самом деле никакого синхронного непрерывного кода при этом нет. Естественно, что обработать таким образом компилятор может только то что в исходниках, а не системные вызовы типа Thread.Sleep.
И да, здесь определенная связь с зелеными потоками есть — в других языках, о которых Икемефула упоминал, для реализации продолжений в основном используют зеленые потоки и реализуют эти самые продолжжения в лоб. Хуже того, лет 10 назад МС даже выкладывал в качестве демонстрации расширяемости CLR Host реализацию продолжений (yield) на системных файберах для обычного древнего C# 1.0.
Я же тут пытаюсь донести мысль, что то что зеленые потоки могут быть использованы для реализации async/await, не делает async/await зелеными потоками.

НС>>Если же пытаться специально обмануть фремворк так, чтобы поставить его раком — это всегда можно сделать, безусловно.
N>Ты вцепился в sleep как финальную однозначность, поэтому вспоминаешь про Delay(). Хорошо, представим себе вместо этого чтение чего-то, что придёт в дескриптор только через минуту. Результат тот же (и см. выше про IO bound).

Результат будет ровно тем же, что и при ручном обращении к IOCP. Таски не занимаются непосредственно своим содержимым, они лишь обеспечивают откработку зависимостей между разными тасками. Т.е., грубо, 99% работы TPL для IO bound заключается в том, чтобы по IOCP колбеку получить данные и запустить те таски, которые ждали либо завершения IO, либо его результата. А все эти танцы с пулом начинаются, только если тебе потом надо что то отработать без IOCP.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ты по прежнему путаешь таски и реализацию continuation monad в компиляторе C#.

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

От тебя требуется объяснить, как же работает код.

То есть, в кратце, тебе надо пояснить, как будет работать в тасках асинхронный код навроде IOCP или таймера того же.

Надо объяснять, что наиболее близко к IOCP это сигнал от таймера, а не Thread.Sleep ?

Ощущение, что ты и sinix путаете две эти вещи.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ты по прежнему путаешь таски и реализацию continuation monad в компиляторе C#.

Кстати говоря, await можно перепилить на колбеки и всунуть это в таски. Интересно, как ты в этом случае будешь выкручиваться.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Да не переключает в тасках никто выполнение нитей. Совсем. Пока конкретная таска выполняется, она владеет потоком ОС монопольно.
I>>А эвентлуп каким то чудом узнает, что вон тот колбек он идет от этого таска, а не от того

НС>Эвентлуп вообще ничего не узнает. Он используется только для отдачи результатов в основной поток при соответствующем контексте.

Ты чего то путаешь. Если поток управления включает в себя эвентлуп, то ни про какой монопольное владение потоком речи быть не может.

Ты не виляй — я ведь привел пример, покажи, как же таска владеет потоком монопольно.

НС>>>Переведи на русский.
I>>Здесь все просто
I>>var x = yield(Task.SomeAwaitable())
I>>получается тот же await

НС>Стало еще меньше понятно о чем ты хотел сказать.

Неудивительно. await, yield — это прямое указание прерывания текущей задачи. Пока await/yield не вернет управление, будет выполняться другая таска.

То есть, await отдаёт управление шедулеру, а вернется управление через эвентлуп и тот же шедулер.

Скажем, как то иначе прикрутить к потоку IOCP или таймер будет сложновато, придется изобрести эвент-луп.