.NET wątki wątków i asynchroniczne wątki IO

Question

OK, jak rozumiem, .NET Threadpool utrzymuje pewną liczbę wątków w tle, gotowych do użycia dla zadań w rodzaju.

Metody Get/SetMinThreads i Get/SetMaxThreads zawierają dwa parametry, które można zwrócić lub dostosować.

Zgodnie z MSDN dwa parametry wskazują liczbę wątków roboczych i liczbę wątków używanych do operacji asynchronicznych IO.

W jakich typach operacji używasz określonego rodzaju nici?

wątków roboczych:

1. QueueUserWorkItem przypuszczam.
2. Coś jeszcze?

asynchroniczny IO wątki:

1. używana podczas wywoływania Beginxxx, Endxxx na strumieniach plików na przykład? (Lub sieć, port szeregowy itp.)
2. Coś jeszcze?

Dziękuję za wyjaśnienia lub dobry link na ten temat.

Answer 1

Tak, metoda QUWI, ale także typu BeginInvoke() typu delegata. I zatrudniony przez kilka klas, BackgroundWorker jest najbardziej znanym przykładem. Które pod maską używa jedynie BeginInvoke() delegata.

Węzły ukończenia we/wy są bardzo niskopoziomową funkcją systemu Windows, która pozwala szybko uruchomić kod po zakończeniu żądania We/Wy. Najbardziej widoczne z ostatniego argumentu funkcji ReadFileEx() są inne. Zarządzany odpowiednik jest wyeksponowany za pomocą ThreadPool.BindHandle().

To jest zadanie klas .NET, aby to naprawić. Tylko kilka z nich wykorzystuje: FileStream, PipeStream, FileSystemWatcher, Socket, wewnętrzny wątek pracownika SerialPort i niektóre klasy wsparcia dla kanału WCF.

Osobiście nie jestem wielkim fanem ujawnienia tych szczegółów konfiguracji w API, szczególnie w wątkach zakończenia operacji we/wy. To trochę wyładowanie przez zespół BCL, trochę FUD po ich zakończeniu. Te ustawienia wpływają na cały program, ustawienia domyślne są już dość hojne. Majsterkowanie z nimi jest mniej więcej równoznaczne z wywołaniem GC.Collect(). Jeśli uda ci się znaleźć dobry powód, żeby je zmienić, lepiej, jeśli utkniesz w piekielnej dziurze, pozostawiając tylko godzinę, by złapać samolot z powrotem do domu. Byłem tam :)