Хабрахабр

Недостаточно знать, что такое Mutex, Semaphore и async/await. Надо знать всё, начиная с квантов

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

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

Небольшой сценарий с семинара

Ведь они могут работать как в параллели друг с другом (когда в данный момент исполняются на разных ядрах), так и что чаще (если речь идёт об одних и тех же потоках) — последовательно. Самое важное, что исходит от операционной системы — это планирование потоков. Второе — для этого отрезка — кванта — может быть выделено разное количество времени. Ведь ОС даёт не так много времени на исполнение — каждому, после чего отдает время другим. Третье — есть приоритеты и понятие "вытесняющая многозадачность", когда ваш поток, только получив заветный квант может его потерять, т.к. Например, в зависимости от того, какой версией ОС мы пользуемся: серверной или пользовательской, является ли поток UI потоком процесса с текущим активным окном. Получается, что наше приложение сильно зависит от того, в каком окружении оно работает. образовался другой поток с более высоким приоритетом. Например, какой-нибудь расчётный сервис лучше всего будет себя чувствовать на серверном варианте ОС (либо с соответствующими настройками производительности), когда на машине нет вообще никаких других сервисов: кванты будут длинными, квантового времени будет предоставлено много.

Почему? Но тут встаёт другой вопрос: если наш поток на такой конфигурации устанавливает блокировку уровня ядра (например, Semaphore(1) ), второй поток дойдя до установки блокировки у себя в эту блокировку встаёт, то стоять он в серверной ОС будет намного дольше, чем стоял бы в пользовательской. Да потому что квант времени серверной в 6 раз длиннее, чем у клиентской и этому потоку придется сначала подождать, когда первый поток дойдёт до места снятия блокировки, а потом — когда ему выдадут новый квант.

Однако, есть помощь и для такого случая: при снятии блокировки у всех потоков, кто её ожидал, временно (на 1 квант) повышается приоритет над другими потоками и второй поток получит процессорное время сразу.

CLRium 6

А он уже богат на информацию, которой можно воспользоваться на всех уровнях: от работы с примитивами синхронизации до работы с высокоуровневыми библиотеками. Эти три абзаца — это сжатые 5% от 4-го доклада. А программа у нас такая:

  1. Мы посмотрим на типы процессов. Ведь их много, а пользуемся мы от силы двумя из них: это обычные и ModernApp;
  2. Три доклада подряд — это потоки уровня операционной системы: планирование на одноядерных, многоядерных системах и NUMA системах. Везде правила — разные и это надо учитывать в своей работе;
  3. Разбор работы примитивов синхронизации на уровне квантового времени. Говорить о lock/Mutex/Semaphore вы все научились на собеседованиях. Нет никакого смысла повторяться, а потому мы вооружимся временными графиками и посмотрим, как распределяются кванты между процессорами на всех примитивах синхронизации: Kernel-Space, User-Space и гибридных.
  4. Настоящий эксклюзив семинара: строение примитива Monitor. То, что lock() раскрывается в try { } finally { } вы и без меня знали, а вот во что раскрывается Monitor.Enter, Monitor.Leave, Monitor.TryEnter — это тема для отдельного, плотного, полного ада доклада. Поверьте, внутри у него всё очень и очень круто. Это — гибридный примитив синхронизации, который построен избегать Starvation, излишних уходов в блокировку и lock convoy.
  5. Целых три плотных доклада по lock-free и wait-free в том числе на примере разведовательных дронов и ПВО, пытающейся сбить эти дроны. И эти доклады настолько понравились HighLoad++, что их позвали на HighLoad++ в Москве 07-08 ноября.
  6. Ряд докладов по PLINQ и Async-Await. Всё тоже максимально подробно. Не по вешкам: этого добра хватает в Интернете. Каждая технология будет рассказана "изнутри": как это принято на CLRium.
  7. И закроют семинар два доклада по библиотеке lock-free коллекций от Microsoft и Intrinsics (векторные инструкции для параллелизации на уровне процессора).

Немного статистики

Вы не выбираете среди докладов, на которые вы не пойдёте. Мы — крупнейший семинар страны и в общем не являемся конференцией только потому, что нам нравится наш формат. При этом вы заранее понимаете, что все темы семинара вам интересны, т.к. Вы идёте на все. На CLRium 6 будет поставлен очередной рекорд: в обоих городах будет присутствовать 700 человек. тема едина. И пойдут на собеседования. Около 700 человек прокачают свои навыки в параллелизации и работой с конкурентностью. Приходите и вы к нам :).

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть