Simple description of worker and I/O threads in .NET

by

The term ‘worker thread’ in .net/CLR typically just refers to any thread other than the Main thread that does some ‘work’ on behalf of the application that spawned the thread. ‘Work’ could really mean anything, including waiting for some I/O to complete. The ThreadPool keeps a cache of worker threads because threads are expensive to create.

The term ‘I/O thread’ in .net/CLR refers to the threads the ThreadPool reserves in order to dispatch NativeOverlapped callbacks from “overlapped” win32 calls (also known as “completion port I/O”). The CLR maintains its own I/O completion port, and can bind any handle to it (via the ThreadPool.BindHandle API). Example here: http://blogs.msdn.com/junfeng/archive/2008/12/01/threadpool-bindhandle.aspx. Many .net APIs use this mechanism internally to receive NativeOverlapped callbacks, though the typical .net developer won’t ever use it directly.

There is really no technical difference between ‘worker thread’ and ‘I/O thread’ — they are both just normal threads. But the CLR ThreadPool keeps separate pools of each simply to avoid a situation where high demand on worker threads exhausts all the threads available to dispatch native I/O callbacks, potentially leading to deadlock. (Imagine an application using all 250 worker threads, where each one is waiting for some I/O to complete).

The developer does need to take some care when handling an I/O callback in order to ensure that the I/O thread is returned to the ThreadPool — that is, I/O callback code should do the minimum work required to service the callback and then return control of the thread to the CLR threadpool. If more work is required, that work should be scheduled on a worker thread. Otherwise, the application risks ‘hijacking’ the CLR’s pool of reserved I/O completion threads for use as normal worker threads, leading to the deadlock situation described above.

Some good references for further reading:
win32 I/O completion ports: http://msdn.microsoft.com/en-us/library/aa365198(VS.85).aspx
managed threadpool: http://msdn.microsoft.com/en-us/library/0ka9477y.aspx
example of BindHandle: http://blogs.msdn.com/junfeng/archive/2008/12/01/threadpool-bindhandle.aspx

More Related Contents:

  1. Could you explain STA and MTA?
  2. Thread vs ThreadPool
  3. BackgroundWorker vs background Thread
  4. Max number of concurrent HttpWebRequests
  5. Is it safe just to set CheckForIllegalCrossThreadCalls to false to avoid cross threading errors during debugging?
  6. Run code on UI thread in WinRT
  7. Double-checked locking in .NET
  8. ApartmentState for dummies
  9. System.Threading.Tasks – Limit the number of concurrent Tasks
  10. Where do I get a thread-safe CollectionView?
  11. Unit testing a multithreaded application?
  12. Making sure OnPropertyChanged() is called on UI thread in MVVM WPF app
  13. Parallelizing GDI+ Image Resizing .net
  14. Identifying the client during a .NET remoting invocation
  15. “The calling thread must be STA, because many UI components require this” error when creating a WPF pop-up Window in thread
  16. Using SynchronizationContext for sending events back to the UI for WinForms or WPF
  17. How to handle all unhandled exceptions when using Task Parallel Library?
  18. Can/Does WPF have multiple GUI threads?
  19. What does MethodImplOptions.Synchronized do?
  20. Entity Framework and Multi threading
  21. DispatcherTimer vs a regular Timer in WPF app for a task scheduler
  22. .NET, the SqlConnection object, and multi-threading
  23. How to prevent a new WPF form from stealing focus?
  24. Does Console.WriteLine block?
  25. Handling Dialogs in WPF with MVVM
  26. .NET Format a string with fixed spaces
  27. Browsing the .NET Framework source code from Visual Studio
  28. Thread parameters being changed
  29. Custom WCF DataContractSerializer
  30. Entity framework 4.3 run migrations at application start

Leave a Comment