Переходят ли Monitor.Pulse и Monitor.Wait в режим ядра?

Джо Даффи в своем сообщении в блоге 2007 года дает обзорное объяснение того, как реализуются переменные состояния, то есть Monitor.Wait/Monitor.Pulse:

Условные переменные реализованы несколько иначе. Каждая среда CLR Объект потока имеет один посвященный ему объект события. Первый когда поток вызывает Wait для условной переменной, событие лениво выделено. И тогда поток просто помещает свой собственный локальный поток. событие в список событий, связанных с монитором. Регистрация событие также требует инфляции для блока синхронизации, если оно не было выполнено. уже произошло, потому что очевидно, что список событий не может быть сохранен в заголовок объекта. Когда случается Pulse, пульсирующая нить просто сигнализирует о первом событии в списке... При появлении PulseAll пульсирующая нить обходит весь список и сигнализирует каждому.

Похоже, что это все еще так, если посмотреть на исходный код для SyncBlock::Pulse и SyncBlock::PulseAll.

void SyncBlock::Pulse()
{
    WaitEventLink  *pWaitEventLink;

    if ((pWaitEventLink = ThreadQueue::DequeueThread(this)) != NULL)
        pWaitEventLink->m_EventWait->Set();
}

void SyncBlock::PulseAll()
{
    WaitEventLink  *pWaitEventLink;

    while ((pWaitEventLink = ThreadQueue::DequeueThread(this)) != NULL)
        pWaitEventLink->m_EventWait->Set();
}

Теперь вопрос в том, является ли этот объект события объектом события ядра.

Из исходного кода из SyncBlock::Wait

 // First time this thread is going to wait for this SyncBlock.
CLREvent* hEvent;
if (pCurThread->m_WaitEventLink.m_Next == NULL) {
    hEvent = &(pCurThread->m_EventWait);
}
else {
    hEvent = GetEventFromEventStore();
}
waitEventLink.m_WaitSB = this;
waitEventLink.m_EventWait = hEvent;
waitEventLink.m_Thread = pCurThread;
waitEventLink.m_Next = NULL;
waitEventLink.m_LinkSB.m_pNext = NULL;
waitEventLink.m_RefCount = 1;
pWaitEventLink = &waitEventLink;
walk->m_Next = pWaitEventLink;

// Before we enqueue it (and, thus, before it can be dequeued), reset the event
// that will awaken us.
hEvent->Reset();

// This thread is now waiting on this sync block
ThreadQueue::EnqueueThread(pWaitEventLink, this);

isEnqueued = TRUE;

CLREvent наследуется от CLREventBase. Глядя на его методы, кажется, что это класс, который должен помочь в хостинговых возможностях CLR -

// Create an Event that is host aware
void CreateAutoEvent(BOOL bInitialState);
void CreateManualEvent(BOOL bInitialState);
// Create an Event that is not host aware
void CreateOSAutoEvent (BOOL bInitialState);
void CreateOSManualEvent (BOOL bInitialState);

Интерфейс IHostManager имеет очень похожий, если не идентичный API и его назначение:

Предоставляет методы, которые позволяют среде CLR создавать примитивы синхронизации, вызывая хост вместо использования функции синхронизации Win32.

Из официального clr-code-guidelines:

У нас есть следующие утвержденные механизмы синхронизации в CLR:

...

События. Хост может предоставлять дескрипторы событий, которые заменяют события Win32.

Итак, похоже, что по умолчанию создается событие CLREvent — это событие Win32.

Это было подтверждено автором этого поста в блоге , немного поработав с WinDbg и пытаясь определить, какой объект события используется Monitor.Enter - AutoResetEvent.

Судя по тому, что я смог покопаться в стеке вызовов Monitor.Wait, это событие изначально задано ManualResetEvent - например здесь

handle = new CLREvent;
_ASSERTE (handle != NULL);
handle->CreateManualEvent(TRUE);
return handle;

и здесь

bool CreateManualEvent(bool initialState)
{
    m_hEvent = CreateEvent(nullptr, true, initialState, nullptr);
    return IsValid();
}

что соответствует его использованию в Syncblock::Wait сверху

// Before we enqueue it (and, thus, before it can be dequeued), reset the event
// that will awaken us.
hEvent->Reset();

В заключение, по умолчанию (без переопределения хоста) вызовы Monitor.Wait и Monitor.Pulse(All) переходят в режим ядра, поскольку они полагаются на события ОС.