Непонятно с async-await в C# - 2
Это не интерпретация - это основы
откуда такая страсть к конспектированию первоисточников? 
Зачем разбираться в чем что не имеет связи с конкретной имплементацией?
нельзя вызвать и получить значение
очень даже можно
Единственно что можно это добавить ее как таск в очередь
Нет в шарпе никаких очередей для этого, есть стейт машина.
Это явный сигнал диспетчеру
нет и специального диспетчера для асинков.
То есть всё, что касается шарпной имплементации совсем не соответствует действительности. Ну зачем такая теория,которая даже и не теория.
я не встретил примера постоянно обновляемого графика
https://arction.com/lightningchart-ultimate-sdk/
не пробовал, но пишут - allows rendering 16 billion data points simultaneously.
Чувствуется научный работник
Я к настоящей науке отношусь примерно как девушка, желающая похудеть, к олимпиадной лёгкой атлетике - ну т.е. тоже что-то там хожу-бегаю вокруг своего дома, как умею, чтобы вес сбросить. Но и только. )))
https://arction.com/lightningchart-ultimate-sdk/
не пробовал, но пишут - allows rendering 16 billion data points simultaneously.
Pricing - Purchase or renew LightningChart .NET subscription - Arction
От полутора килобаксов на одного разработчика. Понятно, что нас нищий научный институт не мог себе такого позволить. Судя по их описанию, они там жуткий "code to metal" использовали - наверняка переписали систему рендеринга для компонента, обходя встроенную в WPF.
Кроме того, есть рекомендация "For best performance in WPF and multithreading benefits, select Non-Bindable chart.". Чарт, насколько я знаю, это одно окошко с графиком - т.е. там все графики должны быть без привязок. Мне иногда нужно было добавить всякие "зоны" с подсветкой и привязками прямо на график. Так что самый быстрый и оптимальный вариант отпадает. А что там реально у них - ещё испытывать надо (30 дней дают). Но в любом случае, для коммерческого распространения - полтора килобакса на разработчика, а Dynamic Data Display бесплатен, т.к. его разработка оплачивалась Майкрософт по одной из их программ по развитию платформы.
У меня примерно так всё выглядело. График слева - "бегущий". По простому варианту вообще в 2-3 тыщи точек (index) укладывались, но это если с OBD по CAN-шине приходили уже посчитанные внутри мозгов движка обороты. Кстати, вспомнил, что эта прога была защищена ключём HASP - там дополнительные настройки и опции в программе скрывались, если специальный разрабский ключ не вставлен в USB. В настрйках дефолтные нереальные значения представлены (не вбиты параметры конкретного устройства), поэтому мощность маленькая.
Вот, кстати, как выглядит отчёт - генерится FlowDocument на WPF, затем сохраняется в XPS или PDF. Контролы с цветными полукругами и шкалами - самописные, с байндингами положений стрелочек по измеренным параметрам. По всему приложению поддерживается многолокальность, но переведено всё лишь на 2 локали - русскую и английскую. Весь отчёт заполняется по объекту результатов - отсылаю результаты во вью-модель отчёта, и дальше вяжу эту вью-моедль ко вьюхе FlowDocument, который затем сохраняется в файл. Ну и плюс результаты отсылаются нам на сервер в базу данных (через WCF service), где и сайт крутится (ASP.NET MVC), который может показать результаты по проведённым опытам и статистику. Единственное, я не разобрался с защитой сайта - ну, чтобы сервис работал через сертификаты. Не успел разобраться с собственным сертификационным центром и самоподписанными сертификатами, и как его к нашему сервису приделать.
Насчёт этой библиотеки графиков - они и для WPF с Win Forms поддерживают, а говорят, что это сейчас на рынке никому не надо и лишь старьё мамонта поддерживать. Но раз продают, занчит покупают для этих платформ, а значит, и новые разработки ведут. Просто на фоне орды джаваскриптеров и мобильных разработчиков это теряется.
Речь то шла прежде всего о быстром, а теперь уже значит и бесплатный.
Вроде рекламируют тоже
https://lvcharts.net/App/examples/Wpf/start
It depends on the case, In general the geared package is really fast, in the best case it can plot 10 million points in a second, but don't trust this, give it a try, you can easily test an application running LiveCharts.Geared by cloning this repository.
Зачем разбираться в чем что не имеет связи с конкретной имплементацией?
Чтобы потом не разбираться в 20 различных имплементациях. Асинхронное программирование и корутины существуют десятки лет, и каждый норовит ввести свои термины и свою специфику.
Нет в шарпе никаких очередей для этого, есть стейт машина.
Если нет очереди, то значит текущие запущенные корутины нигде не хранятся, а значит система и не может их выполнить (она про них ничего не знает). Значит ничего выполняться вообще не будет.
нет и специального диспетчера для асинков.
А кто тогда решает, что выполнять в следующий момент из нескльких альтернативных вариантов? Если никто не рашает (диспетчера ведь нет), то значит в C# можно выполнять только чисто последовательные программы.Классный язык - мне нравится.
И тогда понимание сути устареет.
-----
Как бы тебе по-проще это объяснить...
Устареет - занание конкретной имплементации.
Но конкретную имплементацию в деталях никто, ну кроме разработчиков, в голове не держит.
В голове держат какую-то модель... и не факт что модель станет неактуальной... а правильная модель - 100% останется...
чтобы просто поехать
-----
Пустыня. Куча дохлых машин. Все водители - передохли.
У тебя - выбор - присоеденится к водителям или найти подходящую систему впрыска для замены твоей сдохшей...
Это, кстати, довольно близкая аналогия к ситуации в программировании...
Нет в шарпе никаких очередей для этого
-----
Это не важно.
Важно что предложенная модель объясняет происходящее...
При компиляции требуется складывать и извлекать элементы в/из стека.
При написании методом рекурсивного спуска - никакого выделенного стека нет.
Но есть рекурсивный вызов процедуры, при котором создаются локальные переменные...
Так что, будем говорить что стек не нужен? и ничего что переменные обычно создаются на стеке.
чтобы просто поехать
-----
Пустыня. Куча дохлых машин. Все водители - передохли.
У тебя - выбор - присоеденится к водителям или найти подходящую систему впрыска для замены твоей сдохшей...
Это, кстати, довольно близкая аналогия к ситуации в программировании...
Я, наверное, сдохну - это проще. )))
При компиляции требуется складывать и извлекать элементы в/из стека.
При написании методом рекурсивного спуска - никакого выделенного стека нет.
Но есть рекурсивный вызов процедуры, при котором создаются локальные переменные...
Так что, будем говорить что стек не нужен? и ничего что переменные обычно создаются на стеке.
Не знаю, про какой стек вы речь ведёте, просто не так давно я давал ссылку на Эрика Липперта, который сказал в том смысле, чтобы мы, пользователи Сишарпа, не заморачивались, где реально создаются переменные - стек, куча или параллельная реальность, ибо это от нас не сильно зависит, и компилятор сам решает, где что создать. Если много переменных создавать, которые должны быть в стеке, а они туда не помащаются, то их создадут в куче.
Туда тоже ещё попасть надо. Тот же немецкий должен быть на хорошем уровне. Да банально надо несколько лет опыта, чтобы язык "примелькался", чтобы разные говоры, интонации, произнесённые при разных условиях, узнаваться начали.
У меня даже ощущение, что устроиться программистом с плохим немецким и даже английским (разговорный на уровне средненького В1, например), но с хорошими знаниями программирования (опять же, не отличными, а просто хорошими) проще, чем на кассу в Лидл.
Важно что предложенная модель объясняет происходящее...
Я как то не привык к сферическим коням в вакууме 
ну вот например программка что была
private static async Task TestWithDirectAwait()
{
Wait1();
Console.WriteLine("after wait1");
await Wait2();
Console.WriteLine("after wait2");
await Wait3();
Console.WriteLine("after wait3");
}
Код сгенерированный компилятором был немного подработан, в итоге получился следующий вывод
***State Machine Main MoveNext -1
***State Machine TestWithDirectAwait MoveNext -1
after wait1
***State Machine Wait2 MoveNext -1
wait2 Start tread id 1 (Main1-1)
***State Machine Wait2 MoveNext 0
wait2 for 2000 is ready after 00:00:02.0550266 tid 4 (Main2-4)
***State Machine TestWithDirectAwait MoveNext 0
after wait2
***State Machine Wait3 MoveNext -1
wait3 Start tid 4 (Main2-4)
***State Machine Wait3 MoveNext 0
wait3 for 1000 is ready after 00:00:03.0750480 tid 6 (Main3-6)
***State Machine TestWithDirectAwait MoveNext 1
after wait3
***State Machine Main MoveNext 0
Summary time 00:00:03.0754335 thread Id 6
Вот объясни мне по модели, как это все работает. При этом у тебя есть только
- State Machine
- Synchronization context
- Execution Context
- ThreadPool
- TaskScheduler
Чего он в самом начале (слайд примерно на 8 минуте) взъелся на то, что для организации async/await что-то там потребляется - аж сотня-другая байт памяти и несколько десятков наносекунд (на каком железе ещё не упомянуто)? А оно должно в принципе бесплатным быть, или как?
Я почему-то думаю, что в каком-нибудь "асинхронном" джаваскрипте организация разных корутин стоит дороже. А создание потоков через Thread в Сишарпе - оно бесплатно?
Вобщем, непонятная претензия без сравнения с альтернативами на Сишарпе и с похожими вещами в других языках.
А ты упрости...
А там нечего убирать, вот часть оригинала. Приложение консольное.
Обыгрывается только лишь енто все остальное отладка
await Task.Delay(delay);
private static async Task TestWithDirectAwait()
{
Wait1();
Console.WriteLine("after wait1");
await Wait2();
Console.WriteLine("after wait2");
await Wait3();
Console.WriteLine("after wait3");
}
private static void Wait1()
{
SetThreadName();
Console.WriteLine($"wait1 Start tid {Thread.CurrentThread.ManagedThreadId} ({Thread.CurrentThread.Name})");
int delay = 3000;
Task.Delay(delay);
SetThreadName();
Console.WriteLine($"wait1 for {delay} is ready after {DateTime.Now - _startTime} tid {Thread.CurrentThread.ManagedThreadId} ({Thread.CurrentThread.Name})");
}
private static async Task Wait2()
{
SetThreadName();
Console.WriteLine($"wait2 Start tid {Thread.CurrentThread.ManagedThreadId} ({Thread.CurrentThread.Name})");
const int delay = 2000;
await Task.Delay(delay);
SetThreadName();
Console.WriteLine($"wait2 for {delay} is ready after {DateTime.Now - _startTime} tid {Thread.CurrentThread.ManagedThreadId} ({Thread.CurrentThread.Name})");
}