Непонятно с async-await в C# - 2
А там нечего убирать
-----
Да неправда ваша, батенька...
Бо, в "модель" ты накидал МНОГО, а в качестве обоснования что оно нужно привел код из которого нужность не вытекает... и даже как бы наоборот - код от "модели" получается полностью оторванным.
У 
Срыв покровов модель показывает как может работать async/await
Не говорю что оно работает именно так, этого от модели не требуется.
Говорю - оно МОЖЕТ работать так.
Причем описание - логично и связно.
Т,е, его легко: частью - запомнить, частью - восстановить.
И на его базе можно строить работоспособный код с использованием async/await.
Что, собственно, и требуется от модели.
Бо, в "модель" ты накидал
А я никогда и не предлагал модель. Есть только конкретный пример.
Не говорю что оно работает именно так
Нут так в том то и дело, на кой мне нужна модель которая которая не объясняет работу моего приложения, а только запутывает еще больше.
этого от модели не требуется.
Это может тебе не требуется, а мне требуется.
ваша тема - подтверждение тому, что "развитие языка программирования" в подавляющем большинстве приводят не к упрощению и удобству, а усложнение понимания кода. в самом безобидном случае - просто syntax sugar.
в с# уже имелись несколько вариантов реализации мультитрейдинга. вполне понятных уже десятилетиями и поколениями. кому не хватало еще этого? "никто не понимает, как оно работает и что будет, но зато не три, а две строчки".
Есть только конкретный пример.
Вот объясни мне по модели, как это все работает. При этом у тебя есть только
- State Machine
- Synchronization context
- Execution Context
- ThreadPool
- TaskScheduler
а мне требуется.
-----
Значит тебе надо поработать над пониманием того что такое модель...
Простейший вариант - идешь в магазин и покупаешь модельку ИЛ-96.
Потом объясняешь самому себе - почему вес не соответствует, почему она не планирует как написано в техдоках, почему грузоподъемность не та... и т.п.
Вот объясни мне по модели
Ты не правильно прочитал
Правильно будет - Вот объясни мне по "твоей" модели
над пониманием того что такое модель.
Скорее нужно определить случаи ее использования.
Возьми вот свой самолетик и учи на нем пилотов летать. 
Зато другая модель отлично с этим справится, при этом и крылья и мотор нужны не будут.
Досмотрел это видео (только английский вариант). Где-то с 20 минуты перестал следить за кодом, что он приводит, и пытаться проверять. Что понял по сути, да и он сам в конце резюмировал - иногда в больших компаниях, типа Амазона, требуется делать сложные вещи и писать десяток асинхронных вызовов один из другого. Ну типа каверзных задачек, где замутят какую-нибудь структуру наследования позаковыристей, а я потом в голове скомпилировать это должен. Ну и таким компаниям тесно со всякими асинками-авейтами - они лезут в потроха и находят там то, что им не нравится. Тогда они начинают на любой чих подменять контексты синхронизации, авейтить события через пачки монад (которые не настоящие монады, а типа самописный фреймворк) и тому подобный лапшекод, который обычному разработчику явно чужд.
Вот он там приводит примеры, что если я сделаю так, а это объявлю так, а потом вызову это через это вот так, то можно поиметь проблемы. По-моему, подобным образом поиметь проблемы можно всегда и везде, а на одних асинках свет клином не сошёлся. Как я уже выше писал - можно и в наследованиях запутаться (потому, кстати, некоторые предпочитают "включения" - так называемое "has a", а не "is a" - та же компонентная система в Unity). Да, асинки не идеальны, но, как он же сам сказал, асинхронного фреймворка идеального нигде нет, а в благословенной джаве только-только якобы задумались, как к проблеме подойти - вот уже три года думают.
По видео этого парня, с асинками нельзя работать нормально, не обвешав их лапшой из тасования контекста синхронизации, самописных монад или костылей для сохранения всех выброшенных исключений, чтобы они не терялись. Печально...
Отдельно умилила фраза про фейсбуковцев, которые переписали строки в С++ и сэкономили на этом 1% производительности. Это якобы сэкономило ресурс сотен (или тысяч? - не помню) машин. Это, наверное, целые миллионы долларов в год, а может и пара десятков. В годовых отчётах Фейсбука подобные числа, наверное, даже не упоминаются, а тут целая команда работала, строки в С++ "ускоряла". Ну явно же парням хотелось премии, и надо было срочно что-то улучшить и отчитаться. А улучшить на 1% всегда найдётся что. Ну нет у ребят другой работы, кроме как по проценту тут или там что-то улучшать. Хорошо устроились. В обычной фирме скажи, что ты тут за месяц-два улучшил что-то узкоспециализированное на 1% - выпнут с работы. )))
Вобщем, как я понял с асинками, есть несколько простых случаев, где их можно использовать легко и приятно, если не выходить за строгие рамки контекста и его ограничений. Шаг влево, шаг вправо, прыжок в потроха фреймворка - лучше расстреляться на месте.
Вот объясни мне по "твоей" модели
-----
Ну так Срыв покровов это и сделал.
При том более чем удовлетворительно...
Возьми вот свой самолетик и учи на нем пилотов летать.
-----
А причем тут Я?
Ты сам выбирал и покупал (строил!) модель - вот теперь объясни почему на ней нельзя обучить пилота летать...
При том более чем удовлетворительно...
Ну так о чем и прошу, возьми эту модель и объясни отчего конкретный пример работает как работает.
Таски это то, что добавляется в event loop и там их куча накапливается. Выполняются они одним потоком, который в явно заданные моменты может перескакивать на другие таски.
Ты сам выбирал и покупал (строил!) модель
Я ничего не строил и не выбирал - это было твое предложение. Причем вне зависимости от того для каких целей мне хочется иметь модель.
сам рекламируешь
-----
Что именно Я "рекламирую"?
Я говорю, что то, что было представлено, вполне достаточно объясняет как используется указанное.
Насколько оно соответствует - не важно.
Можно ли приблизить к реальному положению вещей - ДА!
Будет ли приближенная к реальности модель сложнее - ДА!
Нужно ли усложнять модель - НЕТ - предложенная достаточна.
Тебе же хочется чтобы вместо предложенной была создана модель идеально отображающая существующее положение и пофиг что она получится настолько сложной, что для ее понимания потребуется строить модель модели...
Чего вы о моделях спорите? Вы лучше скажите, вы реально применяете асинки не так по-простому, как в тьюториалах в МСДН, а обмазываете подменой контекстов, добавлением монадоподобных самописных фреймворков и прочими вещами? Вроде, асинки не для того были сделаны, чтобы так сложно с ними обращаться? А получается чуть ли не то, что сделать всё через ручное создание потоков проще - хотя бы контролируешь больше и понимаешь, что происходит, а не магия какая-то под копотом. Ну или тупо старые паттерны применять с цепочкой вызовов "задача, задача после окочания задачи, задача, если произошло исключение". Но при приёме на работу-то сейчас все хотят, чтобы ты именно в асинках разбирался.
Насколько оно соответствует - не важно.
Это смотря для чего. Пойти с пацанами в войнушки с самолетиком поиграть, пойдет, возможно.
Но я не хочу иметь машинку с квадратными колесами.
была создана модель идеально отображающая существующее положение
Подобная модель не имеет смысла
для какой цели нужна модель
-----
У ТС определено что именно надо покрыть моделью...
Всё, что я понял - асинки это не обязательно мультипоток. И если будешь выё..., ну т.е. писать много лапши с асинками, то почти наверняка получишь дедлок. А все эти "тут захватываем контекст, тут не захватываем, тут в монады заворачиваем" - это для автомехаников 80 уровня, досконально знающих, что происходит под капотом.
Вон, даже Адам Фурманек подобное по бумажке читает (заранее подготовленным примерам с подсказками). ))) А я на собесах должен это всё из головы доставать? Да ещё спонтанно на рандомный вопрос?
Да и "в бою", сами понимаете, нет времени долго думать - по "2-3 задачи в минуту" надо решать. Майкрософт и все остальные в своих поделках не могут сделать нормальный асинхронный фреймворк, а джуниор-миддл Алекс должен вам тут за пять минут всё профессионально раскидать? ))