Wann genau geht .NET Monitor in den Kernel-Modus?

Die meisten dieser Fragen können beantwortet werden, indem man sich den CLR-Quellcode anschaut, der über die SSCLI20 Verteilung . Es wird ziemlich alt, es ist .NET 2.0 Vintage, aber eine Menge der CLR-Kernfunktionen haben sich nicht viel verändert.

Die Quellcodedatei, die Sie betrachten möchten, ist clr / src / vm / syncblk.cpp. Drei Klassen spielen dabei eine Rolle: AwareLock ist die Low-Level-Sperrimplementierung, die für die Erfassung der Sperre zuständig ist, SyncBlock ist die Klasse, die die Warteschlange von Threads implementiert, die auf eine Sperre warten, CLREvent ist der Wrapper für die Betriebssystemsynchronisierung Objekt, nach dem du fragst.

Das ist C ++ - Code und die Abstraktionsstufe ist ziemlich hoch, dieser Code interagiert stark mit dem Garbage Collector und es ist eine Menge Testcode enthalten. Also werde ich eine kurze Beschreibung des Prozesses geben.

SyncBlock hat das Mitglied m_Monitor, in dem die AwareLock-Instanz gespeichert ist. SyncBlock :: Enter () ruft AwareLock :: Enter () direkt auf. Es versucht zuerst, das Schloss so billig wie möglich zu erwerben. Überprüfen Sie zuerst, ob der Thread die Sperre bereits besitzt und erhöhen Sie die Sperrzahl, wenn dies der Fall ist. Verwenden Sie als Nächstes FastInterlockCompareExchange (), eine interne Funktion, die Interlocked.CompareExchange () sehr ähnlich ist. Wenn die Sperre nicht ausgeführt wird, ist dies sehr schnell erfolgreich und Monitor.Enter () gibt zurück. Wenn nicht, dann besitzt bereits ein anderer Thread die Sperre, AwareLock :: EnterEpilog wird verwendet. Der Thread-Scheduler des Betriebssystems muss eingebunden werden, damit CLREvent verwendet wird. Es wird bei Bedarf dynamisch erstellt und die WaitOne () -Methode aufgerufen. Das wird einen Kernel-Übergang beinhalten.

Also genug, um Ihre Frage zu beantworten: Die Monitor-Klasse tritt in den Kernel-Modus ein, wenn die Sperre besteht und der Thread warten muss.

Ich möchte eine Liste aller möglichen Bedingungen kompilieren, die Monitor in den Kernelmodus bringen / Kernel-Sync-Objekt verwenden.

Der Sync-Block hat ein Feld, um auf das Kernel-Objekt zu verweisen, daher habe ich daraus abgeleitet, dass %code% irgendwann in den Kernel-Modus wechselt.

Ich fand das: Lock (Monitor) interne Implementierung in .NET

Aber es gibt zu viele Fragen, die beantwortet werden müssen, und die einzige nützliche Information ist, dass das OP seine eigene Frage beantwortet hat, indem es einfach gesagt hat, dass die %code% irgendwann in den Kernel-Modus gehen wird. Auch gibt es keine Links zu irgendetwas, um diese Antwort zu unterstützen.

Meine Frage ist anders - Ich möchte wissen, wann genau %code% in den Kernel-Modus geht (nicht wenn und nicht warum - wann).

Ich bin mehr interessiert an .NET 4 und 4.5, wenn es einen Unterschied zu älteren Versionen gibt

BEARBEITEN: Aus dem Richter-Buch: "Ein Synchronisierungsblock enthält Felder für ein Kernel-Objekt, die ID des besitzenden Threads, eine Rekursionsanzahl und eine Anzahl wartender Threads."

Die meisten dieser Fragen können beantwortet werden, indem man sich den CLR-Quellcode anschaut, der über die SSCLI20 Verteilung . Es wird ziemlich alt, es ist .NET 2.0 Vintage, aber eine Menge der CLR-Kernfunktionen haben sich nicht viel verändert.

Die Quellcodedatei, die Sie betrachten möchten, ist clr / src / vm / syncblk.cpp. Drei Klassen spielen dabei eine Rolle: AwareLock ist die Low-Level-Sperrimplementierung, die für die Erfassung der Sperre zuständig ist, SyncBlock ist die Klasse, die die Warteschlange von Threads implementiert, die auf eine Sperre warten, CLREvent ist der Wrapper für die Betriebssystemsynchronisierung Objekt, nach dem du fragst.

Das ist C ++ - Code und die Abstraktionsstufe ist ziemlich hoch, dieser Code interagiert stark mit dem Garbage Collector und es ist eine Menge Testcode enthalten. Also werde ich eine kurze Beschreibung des Prozesses geben.

SyncBlock hat das Mitglied m_Monitor, in dem die AwareLock-Instanz gespeichert ist. SyncBlock :: Enter () ruft AwareLock :: Enter () direkt auf. Es versucht zuerst, das Schloss so billig wie möglich zu erwerben. Überprüfen Sie zuerst, ob der Thread die Sperre bereits besitzt und erhöhen Sie die Sperrzahl, wenn dies der Fall ist. Verwenden Sie als Nächstes FastInterlockCompareExchange (), eine interne Funktion, die Interlocked.CompareExchange () sehr ähnlich ist. Wenn die Sperre nicht ausgeführt wird, ist dies sehr schnell erfolgreich und Monitor.Enter () gibt zurück. Wenn nicht, dann besitzt bereits ein anderer Thread die Sperre, AwareLock :: EnterEpilog wird verwendet. Der Thread-Scheduler des Betriebssystems muss eingebunden werden, damit CLREvent verwendet wird. Es wird bei Bedarf dynamisch erstellt und die WaitOne () -Methode aufgerufen. Das wird einen Kernel-Übergang beinhalten.

Also genug, um Ihre Frage zu beantworten: Die Monitor-Klasse tritt in den Kernel-Modus ein, wenn die Sperre besteht und der Thread warten muss.

Wenn das Schloss stark beansprucht wird.

Wenn die Sperre schwach ist, gibt es einen schnellen CPU-Spinlock, um darauf zu warten, dass die Sperre wieder frei ist, aber wenn dieser nicht lange genug wartet, dass die Sperre frei ist, blockiert der Thread den Mutex Dies beinhaltet einen Aufruf im Kernelmodus, um den Thread und andere solche Verwaltungsaufgaben zu unterbrechen.

Nach dem Spinwait-Schritt.

zusätzliche Intelligenz kann vorhanden sein, wie zum Beispiel das Überspringen von Spinwait auf Einzelkernmaschinen, da die umkämpfte Sperre erst nach Freigabe des Threads freigegeben werden konnte.

Nach dem Spinwait-Schritt.

zusätzliche Intelligenz kann vorhanden sein, wie zum Beispiel das Überspringen von Spinwait auf Einzelkernmaschinen, da die umkämpfte Sperre erst nach Freigabe des Threads freigegeben werden konnte.