Free-ebooks-library - Bahar Ali Khan

There are a few things to be wary of when using pooled threads:
• You cannot set the Name of a pooled thread, making debugging
more difficult (although you can attach a description
when debugging in Visual Studio’s Threads window).
• Pooled threads are always background threads (this is usually
not a problem).
• Blocking a pooled thread may trigger additional latency in
the early life of an application unless you call Thread
Pool.SetMinThreads (see the section “Optimizing the
Thread Pool” on page 805).
You are free to change the priority of a pooled thread—it will
be restored to normal when released back to the pool.
You can query if you’re currently executing on a pooled thread via the property
Thread.CurrentThread.IsThreadPoolThread.
Entering the Thread Pool via TPL
You can enter the thread pool easily using the Task classes in the Task Parallel Library.
These were introduced in Framework 4.0: if you’re familiar with the older
constructs, consider the nongeneric Task class a replacement for ThreadPool.QueueU
serWorkItem, and the generic Task a replacement for asynchronous delegates.
The newer constructs are faster, more convenient, and more flexible than the
old.
To use the nongeneric Task class, call Task.Factory.StartNew, passing in a delegate
of the target method:
static void Main() // The Task class is in System.Threading.Tasks
{
Task.Factory.StartNew (Go);
}
static void Go()
{
Console.WriteLine ("Hello from the thread pool!");
}
Task.Factory.StartNew returns a Task object, which you can then use to monitor the
task—for instance, you can wait for it to complete by calling its Wait method.
Any unhandled exceptions are conveniently rethrown onto the
host thread when you call a task’s Wait method. (If you don’t
call Wait and abandon the task, an unhandled exception will
shut down the process, as with an ordinary thread.)
Thread Pooling | 801
Threading