- PVSM.RU - https://www.pvsm.ru -
Совсем скоро, 29-30 ноября в Санкт-Петербурге и 06-07 декабря — в Москве мы запустим шестой семинар по .NET [1]. На этот раз — по теме многопоточки и конкурентности. Мы уже писали об этом пару раз на Хабре, но сегодня есть отдельный повод для этого: на семинаре настоящий эксклюзив. Будет описана работа гибридного примитива синхронизации: Monitor
. Да, всем привычная вещица достойна отдельного доклада. Ведь он в своей работе учитывает и частоту процессора и количество ядер, учитывает lock convoy/starvation и вообще, очень сложен.
А в конце статьи развлечения ради предложу пройти парочку QUIZов по многопоточке.
Самое важное, что исходит от операционной системы — это планирование потоков. Ведь они могут работать как в параллели друг с другом (когда в данный момент исполняются на разных ядрах), так и что чаще (если речь идёт об одних и тех же потоках) — последовательно. Ведь ОС даёт не так много времени на исполнение — каждому, после чего отдает время другим. Второе — для этого отрезка — кванта — может быть выделено разное количество времени. Например, в зависимости от того, какой версией ОС мы пользуемся: серверной или пользовательской, является ли поток UI потоком процесса с текущим активным окном. Третье — есть приоритеты и понятие "вытесняющая многозадачность", когда ваш поток, только получив заветный квант может его потерять, т.к. образовался другой поток с более высоким приоритетом. Получается, что наше приложение сильно зависит от того, в каком окружении оно работает. Например, какой-нибудь расчётный сервис лучше всего будет себя чувствовать на серверном варианте ОС (либо с соответствующими настройками производительности), когда на машине нет вообще никаких других сервисов: кванты будут длинными, квантового времени будет предоставлено много.
Но тут встаёт другой вопрос: если наш поток на такой конфигурации устанавливает блокировку уровня ядра (например, Semaphore(1) ), второй поток дойдя до установки блокировки у себя в эту блокировку встаёт, то стоять он в серверной ОС будет намного дольше, чем стоял бы в пользовательской. Почему? Да потому что квант времени серверной в 6 раз длиннее, чем у клиентской и этому потоку придется сначала подождать, когда первый поток дойдёт до места снятия блокировки, а потом — когда ему выдадут новый квант.
Однако, есть помощь и для такого случая: при снятии блокировки у всех потоков, кто её ожидал, временно (на 1 квант) повышается приоритет над другими потоками и второй поток получит процессорное время сразу.
Эти три абзаца — это сжатые 5% от 4-го доклада. А он уже богат на информацию, которой можно воспользоваться на всех уровнях: от работы с примитивами синхронизации до работы с высокоуровневыми библиотеками. А программа у нас такая:
Monitor
. То, что lock(){}
раскрывается в try { } finally { }
вы и без меня знали, а вот во что раскрывается Monitor.Enter
, Monitor.Leave
, Monitor.TryEnter
— это тема для отдельного, плотного, полного ада доклада. Поверьте, внутри у него всё очень и очень круто. Это — гибридный примитив синхронизации, который построен избегать Starvation, излишних уходов в блокировку и lock convoy.Мы — крупнейший семинар страны и в общем не являемся конференцией только потому, что нам нравится наш формат. Вы не выбираете среди докладов, на которые вы не пойдёте. Вы идёте на все. При этом вы заранее понимаете, что все темы семинара вам интересны, т.к. тема едина. На CLRium 6 будет поставлен очередной рекорд: в обоих городах будет присутствовать 700 человек. Около 700 человек прокачают свои навыки в параллелизации и работой с конкурентностью. И пойдут на собеседования. Приходите и вы к нам :).
Автор: Stanislav Sidristij
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/c-2/334942
Ссылки в тексте:
[1] шестой семинар по .NET: http://clrium.ru/register.html
[2] HighLoad++ в Москве 07-08 ноября: https://www.highload.ru/moscow/2019/abstracts/6012
[3] Источник: https://habr.com/ru/post/473726/?utm_source=habrahabr&utm_medium=rss&utm_campaign=473726
Нажмите здесь для печати.