Jest to jedno z tych pytań implementacji języka CLR, na które nie ma prostej odpowiedzi. Odstępstwo od CLR nie zależy od implementacji ThreadPool. Jest to zadanie hosta CLR . Warstwa oprogramowania integrująca CLR z systemem operacyjnym. Podstawowym interfejsem używanym przez środowisko CLR do wykonywania czynności związanych z wątkami jest IHostThreadPoolManager. Jest to niezarządzany interfejs COM, ale nie będziesz miał problemu z rozpoznaniem mapowania typu "jeden do jednego" z członkami klasy ThreadPool.
Istnieje wielu implementacji hosta CLR. Te bardziej rozpoznawalne są domyślnym hostem CLR dla aplikacji komputerowych, zaimplementowanym przez mscoree.dll. Istnieją różne wersje dla różnych wersji Windows. I ASP.NET, serwer Sql, proces Visual Studio Hosting, niestandardowy host dla Silverlight, Windows Phone, XBox. A te mniej rozpoznawalne, duże niezarządzane aplikacje mogą same obsługiwać CLR w celu obsługi skryptów zaimplementowanych w języku .NET. Programy CAD, takie jak AutoCAD itp. Są standardowymi przykładami.
Podstawowe pojęcie wątku jest zwirtualizowane w środowisku CLR. IClrTask i IClrTaskManager to interfejsy hostingu do tego. Co pozwala gospodarzowi zaimplementować wątek na czymś innym niż wątek systemu operacyjnego. Jak włókno. Nikt tak naprawdę tego nie robi.
Oczywiście, system Windows ma swój własny interfejs API dla pliku wątków. Funkcja winapi CreateThreadPool() pobiera piłkę. Jednak szturchanie plików mscor * .dll na moim komputerze przy użyciu dumpbin.exe/imports nie jest używane. Przynajmniej część problemu może polegać na tym, że funkcja CreateThreadPool() jest późniejszą funkcją Winapi, dostępną tylko od wersji Vista. XP i wcześniejsze wersje Windows miały znacznie prostszą implementację. Tak więc, nie, przynajmniej dla wersji .NET 4.5.2 dla komputerów stacjonarnych, pula wątków Windows nie wydaje się być istotna.
Gdy pytasz o coś, co czytasz, dołącz link (lub przynajmniej nazwę publikacji). –