В этой статье мы продолжим разбирать содержание работы Stephen Toub-а: «How Async/Await Really Works in C#». В этот раз, в след за автором исходного Поста мы рассмотрим код, который генерирует C# компилятор для реализации асинхронных вызовов и множество связанных с этим сущностей-понятий-приемов, таких как: контекст исполнения, боксинг, стейт машина, стек, потоки, … Эта 6-я часть, пожалуй, основная часть всей работы, которая непосредственно отвечает на вопрос: «Как на самом деле Async/Await работают (и компилируются) в C#»

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

Возможно вам будет интересно сравнить эту мою работу с первоначальным переводом.

В одной из предыдущих статей, посвященных анализу этого (все того же) Поста, я написал что «не возьмусь переписать всю эту хитрую логику, связанную с формированием последовательности вызовов сгенерированной функции на человеческом языке». Но подробно разбирая 5-ю главу того Поста у меня это вроде бы все-таки получилось сделать. Прошу вас оценить результаты этого труда.

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

Чисто техническое, но не очень глубокое описание реализованной задачи с самыми простыми расчетами. Надеюсь, будет полезно соответствующим техническим специалистам или для тех, кто хочет понимать что-то про объем знаний необходимых для использования DMA над некоторым устройством периферии, например SPI.

Относительно использования Ethernet, дальше нескольких упоминаний речь не идет. Как-то, к слову, не пришлось, еще пока. Не обессудьте.

В интернете можно найти описание проблем, связанных с использованием DMA для стандартной функции копирования данных из памяти в память:

Linux – DMA memcpy operation in Linux

Давайте попробуем разобраться, как можно использовать интерфейс к DMA для реализации стандартной операции копирования memcpy и есть ли в этом смысл.

В этот раз я достаточно внимательно прочитал перевод главы про задачи(Tasks) из этого Поста, чтобы выяснить, что он не очень точно передает смысл исходного текста. Я попробую пересказать содержание так, как я его понял, в том числе полагаясь на свой практический опыт программирования многопоточных приложений и embedded приложений с множеством прерываний.

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

Пару ссылок на предыдущие работы по этой теме вы тоже найдете под катом.

Насколько я понял из комментариев к своим предыдущим статьям по этой теме:

1. Часть 1. Проблемы модели асинхронного программирования (APM)

2. Уроки по асинхронному программированию из первой половины работы

3. Параллельные вычисления — Все дело в контексте-синхронизации (SynchronizationContext)

4. Async/Await из C#. Головоломка для разработчиков компилятора и для нас

и по количеству просмотров, тема все еще вызывает интерес, поэтому я хочу попробовать продолжить, но не просто перевод, а перевод С ПОЯСНЕНИЯМИ, хотя и сам перевод тоже должен отличаться от первоначального варианта, поскольку я его не читал, только по результатам, мельком, глянул пару абзацев. К тому же автор того первоначального перевода просил помощи с переводом, поэтому я надеюсь, мой вариант в чем-то сможет помочь в этом смысле или просто будет интересен с точки зрения сравнения.

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

На рисунке приведена структурная схема современного, одного из самых навороченных (я подозреваю) 32-битного ARM процессора или микроконтроллера-microcontroller, в документации используются оба термина: high-performance Flash microcontroller (MCU) based on the 32-bit ARM Cortex-M7 RISC (х.хх CoreMark/MHz) processor.

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

Все это богатство убирается в микросхеме, которая по объему заметно меньше спичечного коробка. Вы легко можете найти достаточно подробное техническое описание (datasheet) узлов, систем, настроек, спецификаций по этой-такой схеме. Давайте попробуем коротко пройтись по одному из таких описанию, ссылки в конце статьи.

Я рискну все таки продолжить изложение своего понимания Поста: How Async/Await Really Works in C#, которое в предыдущей статье получило название “ортогональный взгляд”. Также, недавно мы познакомились (возможно несколько преждевременно) с изначальным определением концепции SynchronizationContext на которую ссылается автор этого Поста.

Это не перевод. Это изложение содержания Поста на разных уровнях раскрытия сущностей и их взаимодействия по мере развития (эволюции) моего понимания тех мыслей и идей, которые, как мне кажется, хотел донести до читателя автор Поста Stephen Toub.

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

В этот раз попробуем сформулировать задачу, которую решает компилятор, то есть те разработчики, которые разрешили нам пользоваться конструкциями Async/Await в C#.

Чтобы до конца разобраться с содержанием Поста: How Async/Await Really Works in C#, который мы начали анализировать в предыдущей статье, неплохо бы познакомиться с изначальным определением концепции SynchronizationContext, на которую ссылается автор этого поста, без которой, по мнению того же автора, нельзя понять реализацию Async/Await.

Это перевод Поста: Parallel Computing - It's All About the SynchronizationContext

Это перевод Поста Allocating Memory for DMA in Linux

В этом посте мы рассмотрим распределение памяти в Linux с использованием очень больших страниц с тем, чтобы совместно использовать эту память с устройствами PCIe, использующими DMA.

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

Теперь это НЕ перевод. Это моя интерпретация тех частей содержания первой половины Поста: Как на самом деле Async/Await работают в C#, которые мне показались заслуживающими внимания в этой работе, с моими пояснениями относительно того почему у меня возникла именно такая интерпретация материала.

Судя по количеству просмотров, работа вызывает интерес, но пробиться сквозь нагромождение терминов трудно даже для подготовленного читателя, как мне кажется. Я хочу попробовать перевести не с английского на русский, а с некоторого кулуарно-профессионального на какой-то более доступный язык. Не знаю, насколько доступный, надеюсь получить некоторый отклик, который поможет мне понять, насколько у меня это получилось. Заранее хочу сказать, что автор действительно изложил как или во что компилируются конструкции Async/Await и, соответственно, как они работают изнутри. Проблема в том, что автору пришлось написать большую подготовительную часть чтобы подвести к изложению этого внутреннего устройства Async/Await. И мне, волей неволей, придется пройтись по всему что предваряет, собственно, основную идею в реализации Async/Await. Поэтому запаситесь терпением либо начинайте читать сразу последнюю часть.

Это обзор только первой половины Поста, возможно по результатам анализа второй половины или по вашим замечаниям мне придётся пересмотреть какие-то мои выводы, я не претендую на абсолютное знание.

Дисклеймер 1

Я подозреваю что некоторых может шокировать, что я объясняю высокие проблемы, связанные с асинхронными вызовами самыми простыми или даже приземленными словами, поэтому не рекомендую читать эту статью слишком чувствительным натурам.

Это перевод первой главы из поста How Async/Await Really Works in C#

Этот пост .Net блога является продолжением исходного поста, глубоко погружающим в историю, приведшую к созданию конструкций async/await и стоящие за этим дизайнерские решения и детали реализации async/await в C# и .NET.

Исходный пост What is .NET, and why should you choose it? предоставляет обзор платформы на высоком-уровне, перечисляя различные компоненты и решения на уровне дизайна, и предваряя последующие посты в глубину обозначенных тем.

Ссылки в развитие темы:

1. Часть 2 Артефакты от EAP шаблона, SynchronizationContext

2. Уроки по асинхронному программированию из первой половины работы

3. Параллельные вычисления — Все дело в контексте-синхронизации (SynchronizationContext)

4. Async/Await из C#. Головоломка для разработчиков компилятора и для нас

Это перевод вступления из электронной книги - документа.

Авторы утверждают что:

В этой главе вы увидите, как можно удовлетворить некоторые из распространенных требований корпоративных приложений (приложений для бизнеса), таких как низкая стоимость (простота) сопровождения и тестируемость, применяя слабосвязанный дизайн для вашего приложения. Вы увидите очень простую иллюстрацию этого подхода в примерах кода, которые показывают два разных способа реализации зависимости между классами ManagementController и TenantStore. Вы также увидите, как принципы объектно-ориентированного программирования SOLID связаны с теми же проблемами (имеются ввиду проблемы стоимости сопровождения = исправления ошибок + возможности расширения функциональности и тестируемости).

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

Адаптированный проект для публичного использования, рабочий на Гите, компилируется в простой exe-файл. Можно скачать как exe-файл, если доверяете своему антивирусу.  Надеюсь, кому-то пригодится. Но чтобы начать пользоваться надо научиться писать XАML определения вложенных структур, по которым работает парсер. Ссылка в конце статьи.

Не будет никаких модных слов, только то, что нужно для работы.

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

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

Последнее время мне приходится много ревьювить, анализировать, рефакторить C# код.  Практика показывает, что принципы Объектно-Ориентированного Программирования не просто вызывают затруднения в понимании, и в применении, в большинстве случаев разработчики просто избегают их использования на практике. Я очень надеюсь, что мой относительно простой пример, который можно не только скомпилировать и выполнить, но и написать свой класс расширения и снова скомпилировать, и оценить результат уже своего труда внутри небольшой законченной программы, надеюсь это поможет кому-то преодолеть барьер к использованию принципов ООП на практике.

Конечно, мне придется продемонстрировать применение на практике принципов ООП: инкапсуляция, наследование, полиморфизм и то, как они работают.

Конечно, разберем как все это влияет на производительность. Я надеюсь, что получится сформулировать некое подобие ответа на критику постулатов «чистого» кода от достаточно успешного (видимо) иностранного программиста в переводе на Хабре: «Чистый» код, ужасная производительность.

Правила «чистого» кода, изложенные в той статье помогут нам подойти к реализации принципов ООП в нашей задаче.

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

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

Мне кажется нельзя считать что вы до конца понимаете концепцию многопоточности (Multithreading/ Concurrency) если вы не понимаете когда (для каких задач) ее можно и/или нужно использовать на однопроцессорной машине, 2-х процессорной, N‑процессорной машине и от чего это зависит.

 Мне давно хотелось узнать существуют ли программисты, которые понимают «делегирование» в рамках ООП так же, как я.  А когда я случайно обнаружил что в Шаблонах проектирования (Design Patterns) в фундаментальных трудах признанных классиков концепций программирования пропущено описание для Делегирования, у меня появился повод написать эту статью.

Так получилось, что я сначала познакомился с этой техникой на практике разрабатывая DirectShow фильтры и COM-объекты, которые составляют эти фильтры и меня особо не интересовало как все это по-умному называется пока это все прекрасно работает. Проблемы возникают, когда ты пытаешься объяснить кому-то КАК это работает, или когда ты пытаешься предложить кому-то хотя бы попробовать использовать определенную технику программирования. Вот именно при таких попытках у меня получилось сопоставить что то, что я использую очень подходит под определение Design Pattern: Delegation.

Давайте посмотрим будет это поводом посмеяться или задуматься.

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

Кто дочитает до конца найдет ответ на вопрос который задает название.

 Что надо знать, чтобы успешно применять-реализовать многопоточность (Multithreading) в своей программе? Мне кажется есть некоторые неудобные для изложения куски в разных описаниях потоков и того, что с ними связано, которые остаются не раскрытыми или вообще пропускаются.

Мне хочется предложить на суд читателей мое собственное понимание таких неудобных аспектов, связанных с применением многопоточности для практического программирования, которое накопилось у меня за пару десятилетий успешного применения этой самой многопоточности на всех уровнях разработки от Embedded и аппаратно-ориентированных уровней до C#, WPF, Java высокоуровневых фронт-ендов.

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

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

Кто-то в коментариях нашел очень интересные аналогии для изложенного в статье решения задачи: https://triztrainer.ru/theory/principles/principle13/

По результатам критики, мне очень интересно было узнать что существует:

"Метод инверсии или методика проектирования «от противного», абсурдной перестановки. Такой подход к проектированию основан на развитии гибкости мышления, поэтому он позволяет получить совершенно новые, порой парадоксальные решения."