В предыдущей публикации мы рассмотрели некоторые базовые вопросы относительно потоков и пулов потоков и готовы двигаться дальше. Давайте проведём эксперимент и найдём правильный объём работы для пула потоков. Чтобы его издержки не давлели над объёмом полезной работы

⚠️ Материал средней сложности

С другой стороны, показанные примеры доказывают, что на производительность сильно влияет гранулярность элементов работы. Имеется ввиду, конечно же, длительность работы делегатов. Чтобы достичь хороших показателей, гранулярность работы не может быть абы какой: она должна быть правильной. И помимо планирования задач на ThreadPool, планировать их можно также как через TPL так и через какой-либо свой собственный пул потоков. Например, если взять обычный ThreadPool, то можно примерно измерить издержки алгоритмов ThreadPool в тактах Time Stamp Counter счётчика времени (можно, конечно и в чём-то более привычном типа микросекунд, но там на многих сценариях вполне могут быть нули)

Эта текст покрывает ответы на некоторые совсем базовые вопросы и вместе с тем сразу погружает в проблематику получения ответа на вопрос: "как работать лучше? однопоточно, многопоточно или многопоточно, но на ThreadPool?". Ответ на этот вопрос может изначально показаться очень простым и понятным, однако реальность совершенно иная: всё как и везде сильно зависит от ситуации: от типа задачи, от её размера, от прочих условий, которые так просто в голову сами собой не придут.

А потому мы пройдёмся в первую очередь по IO-/CPU-bound операциям, стоимости создания потока, базовым основам работы пула потоков (но только основы), а далее -- углубимся в анализ чёрного ящика: от чего зависит производительность пула потоков? Каков объём работы приемлим для того чтобы в него планировать?

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

Также отмечу, что материал постепенно переходит от начального уровня сложности ? через ⚠️ средний уровень к ☠️ высокому, о чём вы сможете узнать по пиктограммам.

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 дело не уйдёт. И очень даже зря.

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

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

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

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

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

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 "Устройство сборщика мусора" от Маони Стевенс.

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

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

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

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

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

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

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

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

Недавно мне повезло пообщаться с Крисом Бэйконом, который написал 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. обеспечение взаимодействия.

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

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

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

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

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

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

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

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

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

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

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

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

Как вы уже заметили, формат семинара эволюционировал и принял новую форму: каждый последующий семинар теперь посвящается целиком и полностью какой-либо теме. Пятый был посвящен теме Garbage Collector и за 10 часов раскрыл всё, что только возможно, оставив за скобками совсем уж частные вопросы. А его кульминацией был доклад про практическое применение (вопрос, который интересует каждого — "зачем всё это знать??")

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