Net framework 5, а также среды Visual Studio 2012 и C#

824
Глава.29 .Примитивные.конструкции.синхронизации.потоков
Примитивные конструкции 
пользовательского режима 
и режима ядра
В этой главе рассматриваются примитивные конструкции для синхронизации по-
токов. Под «примитивными» я подразумеваю простейшие конструкции, которые 
доступны в коде. Они бывают двух видов: пользовательского режима и режима ядра. 
По возможности нужно задействовать первые, так как они значительно быстрее 
вторых и используют для координации потоков специальные директивы процес-
сора. То есть координация имеет место уже на аппаратном уровне (и именно это 
обеспечивает быстродействие). Однако одновременно это означает, что блокировка 
потоков на уровне примитивной конструкции пользовательского режима опера-
ционной системой Windows просто не распознается. А так как заблокированным 
таким способом поток пула не считается таковым, пул не создает дополнительных 
потоков для восполнения загрузки процессора. Кроме того, блокировка происходит 
на очень короткое время.
Звучит заманчиво, не правда ли? Более того, все действительно так, именно 
поэтому я рекомендую использовать эти конструкции как можно чаще. Впрочем, 
они не идеальны. Только ядро операционной системы Windows может остановить 
выполнение потока, чтобы он перестал впустую расходовать ресурсы процессора. 
Запущенный в пользовательском режиме поток может быть прерван операционной 
системой, но довольно быстро снова будет готов к работе. В итоге поток, который 
пытается, но не может получить некоторый ресурс, начинает циклически существо-
вать в пользовательском режиме. Потенциально это является пустым расходованием 
времени процессора, которое лучше было бы потратить с пользой — или просто 
разрешить процессору простаивать для экономии энергии.
Это заставляет нас перейти к примитивным конструкциям режима ядра. Они 
предоставляются самой операционной системой Windows и требуют от потоков 
приложения вызова функций, реализованных в ядре. Переход потока между поль-
зовательским режимом и режимом ядра требует значительных затрат ресурсов, 
поэтому конструкций режима ядра крайне желательно избегать
1
. Однако и у них 
есть свои достоинства. Если один поток использует конструкцию режима ядра для 
получения доступа к ресурсу, с которым уже работает другой поток, Windows бло-
кирует его, чтобы не тратить понапрасну время процессора. А затем, когда ресурс 
становится доступным, блокировка снимается, и поток получает доступ к ресурсу.
Если поток, использующий в данный момент конструкцию, не освободит ее, 
ожидающий конструкции поток может оказаться заблокированным навсегда. В этом 
случае в пользовательском режиме поток бесконечно исполняется процессором; 
этот вариант блокировки называется 
активной (живой) блокировкой
(livelock), 
1
Чуть дальше в этой главе показана программа, измеряющая производительность.

---

825
Конструкции.пользовательского.режима
или 
зависанием
. В режиме ядра поток блокируется навсегда, этот тип блокировки 
называется 
взаимной (мертвой) блокировкой
(deadlock). Обе ситуации по-своему 
плохи, но если выбирать из двух зол, второй вариант видится более предпочти-
тельным, потому что в первом случае впустую расходуются как время процессора, 
так и память (стек потока и т. п.), а во втором случае расходуется только память
1
.
В идеальном мире у нас были бы конструкции, сочетающие лучшие особенности 
обоих типов: быстро работающие и не блокирующиеся (как конструкции пользова-
тельского режима) в условиях отсутствия конкуренции. А если конструкции начи-
нали бы соперничать друг другом, их блокировало бы ядро операционной системы. 
Описанные конструкции даже существуют в природе, я называю их 
гибридными
(hybrid constructs), и мы рассмотрим их в следующей главе. Именно гибридные 
конструкции обычно используются в приложениях, так как в большинстве прило-
жений несколько потоков крайне редко пытаются одновременно получить доступ 
к одним и тем же данным. Гибридные конструкции основное время поддерживают 
быструю работу приложения и периодически замедляются, блокируя поток. Одна-
ко это замедление в тот момент не имеет особого значения, потому что поток все 
равно будет заблокирован.
Многие из конструкций синхронизации потоков в CLR являются всего лишь объ-
ектно-ориентированными оболочками классов, построенных на базе конструкций 
синхронизации потоков Win32. В конце концов, CLR-потоки являются потоками 
операционной системы Windows, которая планирует и контролирует их синхро-
низацию. Конструкции синхронизации существуют с 1992 года и о них написано 
множество книг
2
, поэтому в этой главе я ограничусь лишь кратким обзором.