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

Глава.29 .Примитивные.конструкции.синхронизации.потоков
С помощью события с автосбросом можно легко реализовать блокировку 
в рамках синхронизации потоков, поведение которого сходно с поведением ранее 
показанного класса 
SimpleSpinLock
:
internal sealed class SimpleWaitLock : IDisposable { 
private readonly AutoResetEvent m_available; 
public SimpleWaitLock() { 
m_available = new AutoResetEvent(true); // Изначально свободен
}
public void Enter() { 
// Блокирование на уровне ядра до освобождения ресурса
m_available.WaitOne(); 
} 
public void Leave() {
// Позволяем другому потоку обратиться к ресурсу
m_available.Set(); 
} 
public void Dispose() { m_available.Dispose(); } 
}
Класс 
SimpleWaitLock
применяется так же, как мы использовали бы класс 
SimpleSpinLock
. Более того, внешне он ведет себя совершенно так же; а вот произ-
водительность двух вариантов блокировки отличается кардинальным образом. При 
отсутствии конкуренции за блокировку класс 
SimpleWaitLock
работает намного 
медленнее класса 
SimpleSpinLock
, поскольку каждый вызов его методов 
Enter
и 
Leave
заставляет поток совершить переход из управляемого кода в ядро и обратно. 
Тем не менее при наличии конкуренции проигравший поток блокируется ядром 
и не зацикливается, не давая впустую тратить ресурсы процессора. Имейте в виду, 
что переходами из управляемого кода в ядро и обратно сопровождается также соз-
дание объекта 
AutoResetEvent
и вызов для него метода 
Dispose
, что отрицательно 
сказывается на производительности. Впрочем, эти вызовы совершаются редко, так 
что не стоит слишком сильно беспокоиться по этому поводу.
Чтобы продемонстрировать разницу в производительности, я написал следую-
щий код:
public static void Main() {
Int32 x = 0;
const Int32 iterations = 10000000; // 10 миллионов
// Сколько времени займет инкремент x 10 миллионов раз?
Stopwatch sw = Stopwatch.StartNew();
for (Int32 i = 0; i < iterations; i++) {
x++;
}
Console.WriteLine("Incrementing x: {0:N0}", sw.ElapsedMilliseconds);
// Сколько времени займет инкремент x 10 миллионов раз, если

---

849
Конструкции.режима.ядра
// добавить вызов ничего не делающего метода?
sw.Restart();
for (Int32 i = 0; i < iterations; i++) {
M(); x++; M();
}
Console.WriteLine("Incrementing x in M: {0:N0}", sw.ElapsedMilliseconds);
// Сколько времени займет инкремент x 10 миллионов раз, если
// добавить вызов неконкурирующего объекта SimpleSpinLock?
SpinLock sl = new SpinLock(false); 
sw.Restart(); 
for (Int32 i = 0; i < iterations; i++) { 
Boolean taken = false; sl.Enter(ref taken); x++; sl.Exit(); 
} 
Console.WriteLine("Incrementing x in SpinLock: {0:N0}",
sw.ElapsedMilliseconds); 
// Сколько времени займет инкремент x 10 миллионов раз, если
// добавить вызов неконкурирующего объекта SimpleWaitLock?
using (SimpleWaitLock swl = new SimpleWaitLock()) {
sw.Restart();
for (Int32 i = 0; i < iterations; i++) {
swl.Enter(); x++; swl.Leave();
}
Console.WriteLine(
"Incrementing x in SimpleWaitLock: {0:N0}", sw.ElapsedMilliseconds);
}
}
[MethodImpl(MethodImplOptions.NoInlining)]
private st
atic void M() { /* Этот метод только возвращает управление */ }
Запустив этот код, я получил следующий результат:
Incrementing x: 
8 Самый быстрый
Incrementing x in M: 69 Медленнее ~9 раз 
Incrementing x in SpinLock: 164 Медленнее ~21 раз
Incrementing x i
n SimpleWaitLock: 8,854 Медленнее ~1107 раз
Как легко заметить, простой инкремент 
x
занимает всего 8 мс. Простой вызов 
метода до и после инкремента увеличивает время выполнения в 9 раз! Выполне-
ние кода в методе, который использует конструкции пользовательского режима, 
заставило код работать в 21 (164/8) раз медленней. А теперь обратите внимание, 
на сколько замедлилась программа при вставке в нее конструкций режима ядра. 
Результат достигается в 1107 (8854/8) раз медленней! Поэтому если можете избе-
жать синхронизации потоков, избегайте ее. Если без нее не обойтись, задействуйте 
конструкции пользовательского режима. Конструкции режима ядра следует ис-
пользовать лишь в самом крайнем случае.

---