18 апреля 2020 в Санкт-Петербурге и 16 мая в Москве пройдёт седьмая мини-конференция по платформе .NET CLRium #7. В этот раз мы будем и говорить и заниматься практикой многопоточного кода. Как и в прошлый раз, все доклады будут придерживаться единой линии повествования. В шестом CLRium мы поднаторели в теории и узнали много нового относительно планировщика потоков, блокировок и неблокирующих алгоритмов. В платформе .NET изучили контексты синхронизации, планировщики задач, как работают сами задачи, async/await и типичные ошибки при его использовании… Мы изучили вообще всё, чтобы уверенно начать заниматься практическими задачами.

В CLRium #7 мы перейдём к практике. Наша программа, наконец, окончательно готова: мы разработали матрицу докладов, которые построены так, что последующие доклады логически вытекают из предыдущих. А кроме самих докладов по желанию будет дана практическая работа на дом, в рамках которой вы приобретете опыт работы над задачами совместно: группами по несколько человек (контролируемых координатором).

Ниже представлена не простая расшифровка доклада с семинара CLRium, а переработанная версия для книги .NET Platform Architecture. Той её части, что относится к потокам.

Потоки и планирование потоков

Что такое поток? Давайте дадим краткое определение. По своей сути поток это:

• Средство параллельного относительно других потоков исполнения кода;
• Имеющего общий доступ ко всем ресурсам процесса.

Очень часто часто слышишь такое мнение, что потоки в .NET — они какие-то абсолютно свои. И наши .NET потоки являются чем-то более облегчённым чем есть в Windows. Но на самом деле потоки в .NET являются самыми обычными потоками Windows (хоть Windows thread id и скрыто так, что сложно достать). И если Вас удивляет, почему я буду рассказывать не-.NET вещи в хабе .NET, скажу вам так: если нет понимания этого уровня, можно забыть о хорошем понимании того, как и почему именно так работает код. Почему мы должны ставить volatile, использовать Interlocked и SpinWait. Дальше обычного lock дело не уйдёт. И очень даже зря.

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

Задача процессора — просто исполнять код. Поэтому с точки зрения процессора есть только один поток: последовательное исполнение команд. А задача операционной системы каким-либо образом менять поток т.о. чтобы эмулировать несколько потоков.

18 апреля 2020 в Санкт-Петербурге и 16 мая в Москве пройдёт семинар по платформе .NET CLRium #7 на котором мы продолжим тему многопоточки: на этот раз с точки зрения практики. Первую часть посетило более 700 человек. Основные темы семинара (программа формируется):

• Архитектура распараллеленного кода
• Тестирование распараллеленного кода, алгоритмов и примитивов синхронизации
• Отладка распараллеленного кода

И в этот раз семинар будет в некотором смысле двухнедельным:

• Сам семинар будет идти день;
• После чего вы получите домашние задания и мы в течение двух недель будем их вместе решать, проверять и давать советы по их улучшению (также будет создана группа в Телеграмм для их динамичного обсуждения);

Также возможна работа в формате собеседований с личным ментором

29-30 ноября в Санкт-Петербурге и 06-07 декабря — в Москве мы запустим шестой семинар по .NET. У нас будет: 700 слушателей, огромные залы, много кофе и зудящее чувство знаний. Чтобы собрать рекордно-длинную программу и количество слушателей мы работали рекордные 5 месяцев. До старта — 9 дней.

Совсем скоро, 29-30 ноября в Санкт-Петербурге и 06-07 декабря — в Москве мы запустим шестой семинар по .NET. На этот раз — по теме многопоточки и конкурентности. Мы уже писали об этом пару раз на Хабре, но сегодня есть отдельный повод для этого: на семинаре настоящий эксклюзив. Будет описана работа гибридного примитива синхронизации: Monitor. Да, всем привычная вещица достойна отдельного доклада. Ведь он в своей работе учитывает и частоту процессора и количество ядер, учитывает lock convoy/starvation и вообще, очень сложен.

А в конце статьи развлечения ради предложу пройти парочку QUIZов по многопоточке.

Совсем скоро, 29-30 ноября в Санкт-Петербурге и 06-07 декабря — в Москве мы запустим шестой семинар по .NET. В рамках семинара мы полным ходом изучаем вопросы многопоточности, которые на самом деле очень и очень сложны. Программа немного меняется, но получается очень хардкорной для вас и волнительной — для нас. Я расширил описание уровня ОС до трёх слотов: теперь там можно будет почерпнуть:

• Кванты времени, их длину, выбор их длины, изменение настроек системы так, чтобы выбрать длину квантов времени
• Динамическое повышение приоритетов потоков и длин квантов в зависимости от разных условий: от признака нахождения окна на переднем плане до освобождения блокировок
• Разработка собственного планировщика UMS потоков

и многое другое. Кофе будет много.

Этот пост — попытка достучаться до издательств. Чтобы те услышали и отнеслись к своим переводам более ответственно.

За свой путь разработчика я купил много различных книг. Книг самых разных издательств. И малых и больших. Прежде всего — больших издательств, у которых есть возможности вложиться в перевод технической литературы. Это были самые разные книги: все мы прошли или проходим через путь поиска себя. И все эти книги объединяло одно: они были переведены так, что их невозможно было читать. Со временем, конечно, привыкаешь и к переводу терминов (про себя переводя на те, которые используются повседневно) и к ломаному стилю изложения, по которому видно что этот текст взят с английского. Однако нет привычки к цене, которую просят издательства за популярные издания.

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

В данной статье вы встретите сразу два источника информации:

1. Полный курс по работе Garbage Collector на русском языке: CLRium #6 (текущий семинар здесь)
2. Перевод статьи из BOTR "Устройство сборщика мусора" от Маони Стевенс.

Введение

Несколько лет назад, мы решили, что настало время поддержать SIMD код в .NET. Мы представили пространство имен System.Numerics с типами Vector2, Vector3,Vector4 и Vector<T>. Эти типы представляют API общего назначения для создания, доступа и оперирования векторными инструкциями, когда это возможно. Они, так же, обеспечивают программную совместимость для тех случаев, где аппаратное обеспечение не поддерживает подходящих инструкций. Это позволило, с минимальным рефакторингом, векторизовать ряд алгоритмов. Как бы там ни было, общность такого подхода делает его сложным в применении с целью получения полного преимущество от всех доступных, на современном аппаратном обеспечении, векторных инструкций. В дополнении, современное аппаратное обеспечение предоставляет ряд специализированных, не векторных, инструкций, которые могут значительно улучшать производительность. В этой статье я расскажу, как мы обошли эти ограничения в .NET Core 3.0.

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

День Программиста традиционно отмечается в 256-й день года. Число 256 выбрано потому, что это количество чисел, которые можно выразить с помощью одного байта (от 0 до 255).

Все мы выбрали эту профессию по-разному. Кто-то вышел на нее случайно, кто-то выбрал специально, но теперь все мы трудимся вместе над одним общим делом: мы создаем будущее. Создаем прекрасные алгоритмы, заставляем эти коробочки работать, работать и еще раз работать, даря людям новые профессии и возможности для самовыражения… Даря людям возможность общаться друг с другом, зарабатывать на жизнь… Мы создаем для людей некоторую — ныне ставшую совершенно незаметной — часть реальности, которая стала настолько привычной и неотъемлемой частью нашей жизни, словно она стала законом природы. Подумайте сами: можно ли представить сегодня мир без интернета, смартфонов, компьютеров? Будь то вирусописатель или программист детских игрушек… Каждый из нас изменил чью-то жизнь…

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

Совсем скоро, 29-30 ноября в Санкт-Петербурге и 06-07 декабря — в Москве мы запустим шестой семинар по .NET. На этот раз — по теме многопоточки и конкурентности. Мы уже писали об этом пару раз на Хабре, но сегодня — День Программиста и есть отличный повод дать вам всем комплимент: скидку на его посещение.

У меня для вас есть новость: мы с Андреем Гончаровым, моим хорошим другом и соратником решили сделать для вас доклады по lock-free, выступая вместе. Мне показалось, это должно сильно оживить атмосферу выступления. Андрей сейчас закапывается в эту тему так, что иногда его приходится даже останавливать: доклады будут очень интересными и полезными.

Юрий Власов, мой второй коллега нашёл библиотеку Microsoft.VisualStudio.Threading, которую с удовольствием использует в проектах. Он решил поведать вам о её богатых возможностях и применимости в различных задачах. Этот доклад отлично завершит тему lock-free, закрыв вопросы теории, оценки сложностей, анализа существующих алгоритмов и построения собственных вопросом хорошей реализации в виде промышленной библиотеки.

В честь Дня Программиста мы ввели промокод: CLRiumDevDay. Он действует всего-лишь два дня, когда можно забронировать билеты. Далее — вы имеете 5 дней на оплату билетов.
Первый день — скидка = 25%, второй = 15%

Пьяный программист сидит с открытым Norton Commander на экране. На обоих панелях открыт диск С. «Ну и зачем мне два диска С с одними и теми же файлами?» — подумал он и стер все его содержимое, нажав F8 и Enter.

— анекдот конца 80-х годов

Нортон (Norton Commander) for DOS – это файловый менеджер для DOS, который существовал в 5 основных версиях – 1.0, 2.0, 3.0, 4.0, 5.0, причем только последняя версия имеет подверсию 5.5. Многие версии до сих пор используются различными энтузиастами и лежат на различных сайтах по сети Интернет.

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

Недавно мне повезло пообщаться с Крисом Бэйконом, который написал DotNetAnywhere (альтернативный вариант .NET Runtime), и я остроумно заметил:

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

если исключить тех, кто на зарплате, т.е. инженеров Microsoft/Mono/Xamarin, их очень немного.

Это — перевод статьи Matt Warren (A History of .NET Runtimes). Дабы не делать повторную публикацию, оставлю as is

.NET – управляемая среда выполнения. Это означает, что в ней представлены высокоуровневые функции, которые управляют вашей программой за вас (из Introduction to the Common Language Runtime (CLR), 2007 г.):

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

1. Основные функции, которые влияют на устройство других. К ним относятся:
   1. сборка мусора;
   2. обеспечение безопасности доступа к памяти и безопасности системы типов;
   3. высокоуровневая поддержка языков программирования.
2. Дополнительные функции– работают на базе основных. Многие полезные программы обходятся без них. К таким функциям относятся:
   1. изолирование приложений с помощью AppDomains;
   2. защита приложений и изолирование в песочнице.
3. Другие функции – нужны всем средам выполнения, но при этом они не используют основные функции CLR. Такие функции отражают стремление создать полноценную среду программирования. К ним относятся:
   
   1. управление версиями;
   2. отладка/профилирование;
   3. обеспечение взаимодействия.

Видно, что хотя отладка и профилирование не являются основными или дополнительными функциями, они находятся в списке из-за ‘стремления создать полноценную среду программирования’.

Предисловие к переводу

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

Введение

Пространство имен System.Threading.Tasks и класс Task впервые были представлены в .NET Framework 4. С тех пор, этот тип, и его производный класс Task<TResult>, прочно вошли в практику программирования на .NET, стали ключевыми аспектами асинхронной модели, реализованной в C# 5, с его async/await. В этой статье я расскажу о новых типах ValueTask/ValueTask<TResult>, которые были введены с целью повышения производительность асинхронного кода, в тех случаях, когда ключевую роль играют накладные расходов при работе с памятью.

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

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

Скажу сразу: я никогда не жду развёрнутого ответа на этот вопрос на собесах. Это глупо и в моем случае — эгоистично. Однако, на мой взгляд, помимо общего интереса к платформе, знать, как он работает очень полезно, т.к. это снимает целый ряд вопросов. Например, исключает вариант, когда разработчик считает, что Dispose вызывается автоматически и вызывать его самому не надо. Или же если разработчик более опытен, помогает ему автоматически, на уровне мышечной памяти писать код, приводящий к наименьшему количеству проблем.

Другой вопрос, что мне субъективно не очень нравится, как объясняется его работа. Потому, предлагаю альтернативный подход, описанный в моей книге, .NET Platform Architecture.

Если мы с вами будем досконально разбираться, почему были выбраны именно эти два алгоритма управления памятью: Sweep и Compact, нам для этого придётся рассматривать десятки алгоритмов управления памятью, которые существуют в мире: начиная обычными словарями, заканчивая очень сложными lock-free структурами. Вместо этого, оставив голову мыслям о полезном, мы просто обоснуем выбор и тем самым поймём, почему выбор был сделан именно таким. Мы более не смотрим в рекламный буклет ракеты-носителя: у нас на руках полный набор документации.

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

Заглянуть «под капот» кода или посмотреть на внутреннее устройство CLR можно с помощью множества инструментов. Этот пост родился из твита, и я должен поблагодарить всех, кто помог составить список подходящих инструментов. Если я пропустил какие-то из них, напишите в комментариях.

Во-первых, я должен упомянуть, что хороший отладчик уже присутствует в Visual Studio и VSCode. Также существует множество хороших (коммерческих) профилировщиков .NET и инструментов мониторинга приложений, на которые стоит взглянуть. Например, недавно я попробовал поработать с Codetrack и был впечатлён его возможностями.

Однако оставшийся пост посвящён инструментам для выполнения отдельных задач, которые позволят лучше понять, что происходит. Все инструменты имеют открытый исходный код.

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

[1] var x = FooWithResultAsync(/*...*/).Result;

//или
[2] FooAsync(/*...*/).Wait();

//или
[3] FooAsync(/*...*/).GetAwaiter().GetResult();

//или
[4] FooAsync(/*...*/)
    .ConfigureAwait(false)
    .GetAwaiter()
    .GetResult();

//или
[5] await FooAsync(/*...*/).ConfigureAwait(false)

//или просто
[6] await FooAsync(/*...*/)

Из общения с авторами таких строк, стало ясно, что все они делятся на три группы:

• Первая группа, это те, кому ничего не известно о возможных проблемах с вызовом Result/Wait/GetResult. Примеры (1-3) и, иногда, (6), типичны для программистов из этой группы;
• Ко второй группе относятся программисты, которым известно о возможных проблемах, но они не знают причин их возникновения. Разработчики из этой группы, с одной стороны, стараются избегать строк вроде (1-3 и 6), но, с другой, злоупотребляют кодом вроде (4-5);
• Третья группа, по моему опыту самая малочисленная, это те программисты, которые знают о том, как код (1-6) работает, и, поэтому, могут сделать осознанный выбор.

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

Функционал Async/Await появился в C# 5, чтобы улучшить скорость отклика пользовательского интерфейса и веб-доступ к ресурсам. Другими словами, асинхронные методы помогают разработчикам выполнять асинхронные операции, которые не блокируют потоки и возвращают один скалярный результат. После многочисленных попыток Microsoft упростить асинхронные операции, шаблон async/await завоевал хорошую репутацию среди разработчиков благодаря простому подходу.

Существующие асинхронные методы значительно ограничены тем, что должны возвращать только одно значение. Давайте рассмотрим некий обычный для такого синтаксиса метод async Task<int> DoAnythingAsync(). Результатом его работы является некоторое одно значение. Из-за такого ограничения нельзя использовать эту функцию с ключевым словом yield и асинхронным интерфейсом IEnumerable<int> (чтобы вернуть результат асинхронного перечисления).