C# ПІДРУЧНИКИ / c# / MS Press - Msdn Training Programming Net Framework With C#

*****************************ILLEGAL FOR NON-TRAINER USE******************************

You can often use thread pooling to make the use multiple threads more efficient. Many applications use multiple threads, but often those threads spend a great deal of time in the sleeping state waiting for an event to occur. Other threads may enter a sleeping state and be awakened only periodically to poll for a change or update status information before going to sleep again.

Advantages of thread pools

Using thread pooling provides your application with a pool of worker threads that are managed by the system, allowing you to concentrate on application tasks rather than thread management. In fact, if you have a number of short tasks that require more than one thread, using the ThreadPool class is the easiest and typically the most efficient way to take advantage of multiple threads.

Thread pooling enables the system to optimize the use of multiple threads for better throughput, not only for your application’s process but also with respect to other processes on the computer. This optimization is transparent to your application. When you use a thread pool, the system can optimize thread time slices, taking into account all of the current processes on your computer.

Using thread pools in the .NET Framework

The .NET Framework uses thread pools for several purposes: asynchronous calls, System.Net socket connections, asynchronous I/O completion, timers, and registered wait operations, among others.

To use a thread pool, call ThreadPool.QueueUserWorkItem from managed code, or CorQueueUserWorkItem from unmanaged code, and pass a WaitCallback delegate that wraps the method that you want to add to the queue.

You can also queue work items that need to be executed when a wait operation completes. You queue these work items by using

ThreadPool.RegisterWaitForSingleObject and passing a WaitHandle and a

WaitOrTimerCallback delegate. When the WaitHandle is signaled or when timed out, it raises a call to the method wrapped by the WaitOrTimerCallback delegate. In both cases the thread pool uses or creates a background thread to invoke the callback method.

Reasons Not to Use Thread Pools

There are several scenarios in which it is appropriate to create and manage your own threads instead of using the ThreadPool class. You should do so when:

!You need a stable identity to be associated with a particular thread. For example, you may want to use a dedicated thread to abort that thread, suspend it, or discover it by name.

The following example shows one way to use the ThreadPool class methods to start multiple threads and monitor their completion:

using System;

using System.Threading;

class Counter

{

public void Read(int threadNum)

{

//…

}

public void Increment(int threadNum)

{

//…

}

}

class App

{

static Counter counter = null;

static int totalNumberOfAsyncOps = 10;

static int numAsyncOps = totalNumberOfAsyncOps; static AutoResetEvent asyncOpsAreDone =

new AutoResetEvent(false);

public static void Main()

{

counter = new Counter(); for (int threadNum = 0;

threadNum < totalNumberOfAsyncOps; threadNum++)

{

ThreadPool.QueueUserWorkItem(

new WaitCallback(UpdateResource), threadNum);

}

asyncOpsAreDone.WaitOne();

}

//…

//The callback method's signature MUST match that of a

//System.Threading.TimerCallback delegate

//(it takes an Object parameter and returns void) static void UpdateResource(Object state)

{

int threadNum = (int) state;

if ((threadNum % 2) != 0) counter.Read(threadNum); else counter.Increment(threadNum);

if (( Interlocked.Decrement(ref numAsyncOps)) == 0) asyncOpsAreDone.Set();

}

}

Demonstration: Using Synchronization Techniques and Thread

Pooling

Topic Objective

To demonstrate various synchronization techniques and the use of the thread pool.

Lead-in

In this demonstration, we’ll look at various synchronization techniques and the use of the thread pool.

*****************************ILLEGAL FOR NON-TRAINER USE******************************

This demonstration shows how to perform synchronization using the C# lock keyword and manual synchronization primitives and how to use the thread pool to obtain multiple threads. The demonstration consists of several test sequences, which are described in this topic.

The classes in the demonstration derive from the class Counter and differ by the technique for synchronization that they implement. For each class’s test, the even number threads execute the class’s Read method, which simply examines and outputs the counter’s value, but does not modify it. The odd number threads execute the class’s Write method, which reads the counter, increments the value, and stores the new value back in the counter.

The code for this demonstration is located in <install folder>\Democode\

Mod14\Demo14.4.

The Mutex test

The Mutex test uses an instance of the CounterUsingMutex class, with the Mutex class to synchronize access to the object so that only one thread at a time executes either of the instance methods. The five Write method calls now increment count by 5, and all the Read operations have a consistent value for count.

The test results in output that is similar to the following:

Mutex test:

Start Resource writing (Thread=0) count: 0

Stop Resource writing (Thread=0) count: 1

Start Resource reading (Thread=3)count: 1

Stop Resource reading (Thread=3) count: 1

Start Resource writing (Thread=4) count: 1

Stop Resource writing (Thread=4) count: 2

Start Resource reading (Thread=5)count: 2

Stop Resource reading (Thread=5) count: 2

Start Resource writing (Thread=6) count: 2

Stop Resource writing (Thread=6) count: 3

Start Resource reading (Thread=7)count: 3

Stop Resource reading (Thread=7) count: 3

Start Resource writing (Thread=8) count: 3

Stop Resource writing (Thread=8) count: 4

Start Resource writing (Thread=2) count: 4

Stop Resource writing (Thread=2) count: 5

Start Resource reading (Thread=1)count: 5

Stop Resource reading (Thread=1) count: 5

Start Resource reading (Thread=9)count: 5

Stop Resource reading (Thread=9) count: 5

All Mutex threads have completed.