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

Глава.30 .Гибридные.конструкции.синхронизации.потоков
// Даем остальным потокам шанс выполниться
// в надежде на снятие блокировки
spinwait.SpinOnce();
}
// Зацикливание завершено, а блокировка не снята,
// пытаемся еще раз
if (Interlocked.Increment(ref m_waiters) > 1) {
// Остальные потоки заблокированы 
// и этот также должен быть заблокирован
m_waiterLock.WaitOne(); // Ожидаем возможности блокирования; 
// производительность падает
// Проснувшись, этот поток получает право на блокирование
// Задаем некоторое состояние и возвращаем управление
}
GotLock:
// Когда поток блокируется, записываем его идентификатор
// и указываем, что он получил право на блокирование впервые
m_owningThreadId = threadId; m_recursion = 1;
}
public void Leave() {
// Если вызывающий поток не заперт, ошибка
Int32 threadId = Thread.CurrentThread.ManagedThreadId;
if (threadId != m_owningThreadId)
throw new SynchronizationLockException(
"Lock not owned by calling thread");
// Уменьшаем на единицу рекурсивный счетчик. Если поток все еще
// заперт, просто возвращаем управление
if (--m_recursion > 0) return;
m_owningThreadId = 0; // Запертых потоков больше нет
// Если нет других заблокированных потоков, возвращаем управление
if (Interlocked.Decrement(ref m_waiters) == 0)
return;
// Остальные потоки заблокированы, пробуждаем один из них
m_waiterLock.Set(); // Значительное падение производительности
}
public void Dispose() { m_waiterLock.Dispose(); }
}
Как видите, оснащение кода блокирования дополнительной логикой увеличи-
вает количество имеющихся полей, а значит, и потребление памяти. Код, который 
должен выполняться, становится сложнее, что также снижает производительность 

---

859
Гибридные.конструкции.в.FCL
блокирования. В главе 29 сравнивалась производительность конструкции, где 
увеличивалось на единицу значение типа 
Int32
без блокирования, а также при-
митивной конструкции пользовательского режима и конструкции режима ядра. 
Я воспроизведу здесь результаты теста, добавив к ним результаты использования 
классов 
SimpleHybridlock
и 
AnotherHybridLock
. Вот они от самого быстрого 
к самому медленному:
Incrementing x: 8 Самый быстрый
Incrementing x in M: 69 Медленнее ~9 раз 
Incrementing x in SpinLock: 164 Медленнее ~21 раз
Incrementing x in SimpleHybridLock: 164 Медленнее ~21 раз (аналогично SpinLock) 
Incrementing x in AnotherHybridLock: 230 Медленнее ~29 раз (из-за владения/
рекурсии)
Incrementing x in SimpleWaitLock: 8,854 Медленнее ~1107 раз
Стоит заметить, что блокировка 
AnotherHybridLock
отнимает в два раза больше 
времени, чем 
SimpleHybridLock
. Это обусловлено дополнительной логикой и про-
веркой ошибок, необходимой для управления владением потоком и рекурсией. 
Как видите, на производительности отрицательно сказывается любая логика, до-
бавляемая в код блокирования.