Was ist der Unterschied zwischen Windows-Thread-Pool und CLR-Thread-Pool

Question

Ich lese einige Segmente über Fenster Thread-Pool. Es sieht aus wie CLR-Thread-Pool.

CLR basiert auf Windows, CLR-Thread basiert also auf Windows-Thread-Pool, stimmt das?

Ich weiß, dass jeder .net-Prozess einen Thread-Pool hat, was ist die Situation in Windows-Thread-Pool? Das Betriebssystem hat einen Thread-Pool oder viele?

In C# kann Entwickler den Fenster-Thread-Pool nach Code steuern?

Answer 1

Es ist eine dieser CLR-Implementierungsfragen, die keine direkte Antwort haben. Es ist nicht die CLR, zu bestimmen, wie der ThreadPool implementiert wird. Es ist die Aufgabe des CLR-Hosts. Eine Softwareschicht, die CLR in das Betriebssystem integriert. Die Kernschnittstelle, die die CLR verwendet, um Thread-Pooly-Dinge zu erledigen, ist IHostThreadPoolManager. Es ist eine nicht verwaltete COM-Schnittstelle, aber Sie werden kaum Probleme haben, die fast eins-zu-eins-Zuordnung mit ThreadPool-Klassenmitgliedern zu erkennen.

Es gibt viele Implementierungen des CLR-Hosts. Die besser erkennbaren sind der Standard-CLR-Host für Desktop-Apps, der von mscoree.dll implementiert wird. Es gibt verschiedene Versionen davon für verschiedene Windows-Versionen. Und ASP.NET, Sql Server, der Visual Studio Hosting-Prozess, der benutzerdefinierte Host für Silverlight, Windows Phone, XBox. Und die weniger bekannten, große nicht verwaltete Anwendungen können die CLR selbst hosten, um das in einer .NET-Sprache implementierte Skripting zu unterstützen. CAD-Programme wie AutoCAD usw. sind Standardbeispiele.

Der Kernbegriff eines Threads wird in der CLR virtualisiert. IClrTask und IClrTaskManager sind die Hosting-Schnittstellen dafür. Dadurch kann ein Host einen Thread auf einem anderen als einem Betriebssystem-Thread implementieren. Wie eine Faser. Niemand macht das tatsächlich.

Sicher, Windows hat seine eigene API für einen Threadpool. Die Winampi-Funktion CreateThreadPool() bringt diesen Ball ins Rollen. Wenn ich jedoch die Dateien mscor * .dll auf meinem Rechner mit dumpbin.exe/imports stoße, sehe ich nicht, dass sie benutzt wird. Zumindest ein Teil des Problems könnte sein, dass CreateThreadPool() eine spätere winapi-Funktion ist, die erst seit Vista verfügbar ist. XP und frühere Windows-Versionen hatten eine viel einfachere Implementierung. Also, zumindest für die Desktop-Version von .NET 4.5.2 scheint der Windows-Threadpool nicht relevant zu sein.