.NET 4.0 C# 线程深度解析

需积分: 10 196 浏览量更新于2024-07-19 收藏 1.13MB PDF 举报

"Threading in C# - 深入探讨.NET 4.0中的线程技术，由Joseph Albahari撰写，英文版图书，涵盖线程创建、同步、线程池等多个方面。" 本文档是关于C#编程语言中线程（Threading）的深入指南，特别针对.NET 4.0框架进行了详细的描述。作者Joseph Albahari在书中讨论了多线程的核心概念和实践应用，旨在帮助开发者理解如何在C#中有效利用线程来提升程序的并发性能。首先，文档介绍了线程的基本概念和工作原理。线程与进程是操作系统资源管理的两个基本单元，它们之间的区别在于线程是进程内的执行流。线程在多任务环境中可以共享同一进程的资源，从而实现高效的并发执行。然而，线程的不当使用可能会导致资源竞争和性能问题，因此作者强调了正确理解和使用线程的重要性。接着，文档详细阐述了如何创建和启动线程。可以通过直接实例化`Thread`类并调用`Start`方法来创建新线程，同时可以传递数据给新线程以执行特定任务。此外，还讨论了线程命名、前台线程与后台线程的区别以及线程优先级的概念，这些都对线程的行为和生命周期管理有着直接影响。线程的异常处理是另一个关键话题，作者指出，当线程中抛出未捕获的异常时，对于前台线程，会终止整个应用程序；而对于后台线程，异常会被忽略，但仍然可能导致资源泄露。因此，良好的异常处理策略是必要的。线程池（ThreadPool）是.NET框架提供的一种优化线程使用的机制。通过任务并行库（TPL）或者直接调用ThreadPool的方法，可以更高效地管理和调度线程，避免频繁创建和销毁线程带来的开销。作者还讨论了如何优化线程池的使用，以提高系统性能。在基本的线程同步部分，作者详细讲解了同步的必要性，如防止数据竞争。他解释了阻塞与自旋等待的区别，并介绍了线程状态。锁定是确保线程安全的关键，如`Monitor.Enter`和`Monitor.Exit`的使用，以及何时应该使用锁。此外，他还讨论了锁的嵌套、死锁和性能问题，以及`Mutex`和`Semaphore`等其他同步原语的应用。这本书籍提供了丰富的C#线程编程知识，包括线程的创建、同步、线程池的使用，以及如何避免常见的多线程问题，是C#开发者深入理解和实践多线程编程的重要参考资料。

Entering the Thread Pool Without TPL

You can't use the Task Parallel Library if you're targeting an earlier version of the .NET Framework (prior to 4.0).

Instead, you must use one of the older constructs for entering the thread pool:

ThreadPool.QueueUserWorkItem

and

asynchronous delegates. The difference between the two is that asynchronous delegates let you return data from the

thread. Asynchronous delegates also marshal any exception back to the caller.

QueueUserWorkItem

To use

QueueUserWorkItem

, simply call this method with a delegate that you want to run on a pooled thread:

static void Main()

{

ThreadPool.QueueUserWorkItem (Go);

ThreadPool.QueueUserWorkItem (Go, 123);

Console.ReadLine();

}

static void Go (object data) //

data

will be null with the first call.

{

Console.WriteLine ("Hello from the thread pool! " + data);

}

// Output:

Hello from the thread pool!

Hello from the thread pool! 123

Our target method,

, must accept a single

object

argument (to satisfy the

WaitCallback

delegate). This provides a

convenient way of passing data to the method, just like with

ParameterizedThreadStart

. Unlike with

Task

QueueUserWorkItem

doesn't return an object to help you subsequently manage execution. Also, you must explicitly

deal with exceptions in the target code—unhandled exceptions will take down the program.

Asynchronous delegates

ThreadPool.QueueUserWorkItem

doesn’t provide an easy mechanism for getting return values back from a thread

after it has finished executing. Asynchronous delegate invocations (asynchronous delegates for short) solve this,

allowing any number of typed arguments to be passed in both directions. Furthermore, unhandled exceptions on

asynchronous delegates are conveniently rethrown on the original thread (or more accurately, the thread that calls

EndInvoke

), and so they don’t need explicit handling.

Don’t confuse asynchronous delegates with asynchronous methods (methods starting with Begin or End, such

File.BeginRead

File.EndRead

). Asynchronous methods follow a similar protocol outwardly, but they

exist to solve a much harder problem, which we describe in Chapter 23 of C# 4.0 in a Nutshell.

Here’s how you start a worker task via an asynchronous delegate:

1. Instantiate a delegate targeting the method you want to run in parallel (typically one of the predefined

Func

delegates).

2. Call

BeginInvoke

on the delegate, saving its

IAsyncResult

return value.

BeginInvoke

returns immediately to the caller. You can then perform other activities while the pooled

thread is working.

3. When you need the results, call

EndInvoke

on the delegate, passing in the saved

IAsyncResult

object.

In the following example, we use an asynchronous delegate invocation to execute concurrently with the main thread, a

simple method that returns a string’s length:

static void Main()

{

Func<string, int> method = Work;

IAsyncResult cookie = method.BeginInvoke ("test", null, null);

// ... here's where we can do other work in parallel...

int result = method.EndInvoke (cookie);

Console.WriteLine ("String length is: " + result);

}

static int Work (string s) { return s.Length; }

EndInvoke

does three things. First, it waits for the asynchronous delegate to finish executing, if it hasn’t already.

Second, it receives the return value (as well as any

ref

out

parameters). Third, it throws any unhandled worker

exception back to the calling thread.

If the method you’re calling with an asynchronous delegate has no return value, you are still (technically)

obliged to call

EndInvoke

. In practice, this is open to debate; there are no

EndInvoke

police to administer

punishment to noncompliers! If you choose not to call

EndInvoke

, however, you’ll need to consider exception

handling on the worker method to avoid silent failures.

You can also specify a callback delegate when calling

BeginInvoke

—a method accepting an

IAsyncResult

object

that’s automatically called upon completion. This allows the instigating thread to “forget” about the asynchronous

delegate, but it requires a bit of extra work at the callback end:

static void Main()

{

Func<string, int> method = Work;

method.BeginInvoke ("test", Done, method);

// ...

}

static int Work (string s) { return s.Length; }

static void Done (IAsyncResult cookie)

{

var target = (Func<string, int>) cookie.AsyncState;

int result = target.EndInvoke (cookie);

Console.WriteLine ("String length is: " + result);

}

The final argument to

BeginInvoke

is a user state object that populates the

AsyncState

property of

IAsyncResult

. It

can contain anything you like; in this case, we’re using it to pass the

method

delegate to the completion callback, so we

can call

EndInvoke

on it.

Optimizing the Thread Pool

The thread pool starts out with one thread in its pool. As tasks are assigned, the pool manager “injects” new threads to

cope with the extra concurrent workload, up to a maximum limit. After a sufficient period of inactivity, the pool

manager may “retire” threads if it suspects that doing so will lead to better throughput.

You can set the upper limit of threads that the pool will create by calling

ThreadPool.SetMaxThreads

; the defaults

are:

• 1023 in Framework 4.0 in a 32-bit environment

• 32768 in Framework 4.0 in a 64-bit environment

• 250 per core in Framework 3.5

• 25 per core in Framework 2.0

(These figures may vary according to the hardware and operating system.) The reason there are that many is to ensure

progress should some threads be blocked (idling while awaiting some condition, such as a response from a remote

computer).

You can also set a lower limit by calling

ThreadPool.SetMinThreads

. The role of the lower limit is subtler: it’s an

advanced optimization technique that instructs the pool manager not to delay in the allocation of threads until reaching

the lower limit. Raising the minimum thread count improves concurrency when there are blocked threads (see sidebar).

The default lower limit is one thread per processor core—the minimum that allows full CPU utilization. On

server environments, though (such ASP.NET under IIS), the lower limit is typically much higher—as much as

50 or more.

How Does the Minimum Thread Count Work?

Increasing the thread pool’s minimum thread count to x doesn’t actually force x threads to be created right

away—threads are created only on demand. Rather, it instructs the pool manager to create up to x threads the

instant they are required. The question, then, is why would the thread pool otherwise delay in creating a thread

when it’s needed?

The answer is to prevent a brief burst of short-lived activity from causing a full allocation of threads, suddenly

swelling an application’s memory footprint. To illustrate, consider a quad-core computer running a client

application that enqueues 40 tasks at once. If each task performs a 10 ms calculation, the whole thing will be

over in 100 ms, assuming the work is divided among the four cores. Ideally, we’d want the 40 tasks to run on

exactly four threads:

• Any less and we’d not be making maximum use of all four cores.

• Any more and we’d be wasting memory and CPU time creating unnecessary threads.

And this is exactly how the thread pool works. Matching the thread count to the core count allows a program to

retain a small memory footprint without hurting performance—as long as the threads are efficiently used

(which in this case they are).

But now suppose that instead of working for 10 ms, each task queries the Internet, waiting half a second for a

response while the local CPU is idle. The pool manager’s thread-economy strategy breaks down; it would now

do better to create more threads, so all the Internet queries could happen simultaneously.

Fortunately, the pool manager has a backup plan. If its queue remains stationary for more than half a second, it

responds by creating more threads—one every half-second—up to the capacity of the thread pool.

The half-second delay is a two-edged sword. On the one hand, it means that a one-off burst of brief activity

doesn’t make a program suddenly consume an extra unnecessary 40 MB (or more) of memory. On the other

hand, it can needlessly delay things when a pooled thread blocks, such as when querying a database or calling

WebClient.DownloadFile

. For this reason, you can tell the pool manager not to delay in the allocation of the

first x threads, by calling

SetMinThreads

, for instance:

ThreadPool.SetMinThreads (50, 50);

(The second value indicates how many threads to assign to I/O completion ports, which are used by the APM,

described in Chapter 23 of C# 4.0 in a Nutshell.)

The default value is one thread per core.

Part 2: Basic Synchronization

Synchronization Essentials

So far, we’ve described how to start a task on a thread, configure a thread, and pass data in both directions. We’ve also

described how local variables are private to a thread and how references can be shared among threads, allowing them to

communicate via common fields.

The next step is synchronization: coordinating the actions of threads for a predictable outcome. Synchronization is

particularly important when threads access the same data; it’s surprisingly easy to run aground in this area.

Synchronization constructs can be divided into four categories:

Simple blocking methods

These wait for another thread to finish or for a period of time to elapse.

Sleep

Join

, and

Task.Wait

are simple

blocking methods.

Locking constructs

These limit the number of threads that can perform some activity or execute a section of code at a time. Exclusive

locking constructs are most common—these allow just one thread in at a time, and allow competing threads to

access common data without interfering with each other. The standard exclusive locking constructs are

lock

(

Monitor.Enter

Monitor.Exit

Mutex

, and

SpinLock

. The nonexclusive locking constructs are

Semaphore

SemaphoreSlim

, and the reader/writer locks.

Signaling constructs

These allow a thread to pause until receiving a notification from another, avoiding the need for inefficient polling.

There are two commonly used signaling devices: event wait handles and

Monitor

’s

Wait

Pulse

methods.

Framework 4.0 introduces the

CountdownEvent

and

Barrier

classes.

Nonblocking synchronization constructs

These protect access to a common field by calling upon processor primitives. The CLR and C# provide the

following nonblocking constructs:

Thread.MemoryBarrier

Thread.VolatileRead

Thread.VolatileWrite

the

volatile

keyword, and the

Interlocked

class.

Blocking is essential to all but the last category. Let’s briefly examine this concept.

Blocking

A thread is deemed blocked when its execution is paused for some reason, such as when

Sleep

ing or waiting for another

to end via

Join

EndInvoke

. A blocked thread immediately yields its processor time slice, and from then on

consumes no processor time until its blocking condition is satisfied. You can test for a thread being blocked via its

ThreadState

property:

bool blocked = (someThread.ThreadState & ThreadState.WaitSleepJoin) != 0;

(Given that a thread’s state may change in between testing its state and then acting upon that information, this code is

useful only in diagnostic scenarios.)

When a thread blocks or unblocks, the operating system performs a context switch. This incurs an overhead of a few

microseconds.

Unblocking happens in one of four ways (the computer's power button doesn't count!):

• by the blocking condition being satisfied

• by the operation timing out (if a timeout is specified)

• by being interrupted via Thread.Interrupt

• by being aborted via Thread.Abort

A thread is not deemed blocked if its execution is paused via the (deprecated) Suspend method.

Blocking Versus Spinning

Sometimes a thread must pause until a certain condition is met. Signaling and locking constructs achieve this efficiently

by blocking until a condition is satisfied. However, there is a simpler alternative: a thread can await a condition by

spinning in a polling loop. For example:

while (!proceed);

or:

while (DateTime.Now < nextStartTime);

In general, this is very wasteful on processor time: as far as the CLR and operating system are concerned, the thread is

performing an important calculation, and so gets allocated resources accordingly!

Sometimes a hybrid between blocking and spinning is used:

while (!proceed) Thread.Sleep (10);

Although inelegant, this is (in general) far more efficient than outright spinning. Problems can arise, though, due to

concurrency issues on the

proceed

flag. Proper use of locking and signaling avoids this.

Spinning very briefly can be effective when you expect a condition to be satisfied soon (perhaps within a few

microseconds) because it avoids the overhead and latency of a context switch. The .NET Framework provides

special methods and classes to assist—see “SpinLock and SpinWait”.

ThreadState

You can query a thread's execution status via its

ThreadState

property. This returns a flags enum of type

ThreadState

, which combines three “layers” of data in a bitwise fashion. Most values, however, are redundant,

unused, or deprecated. The following diagram shows one “layer”:

The following code strips a

ThreadState

to one of the four most useful values:

Unstarted

Running

WaitSleepJoin

, and

Stopped

public static ThreadState SimpleThreadState (ThreadState ts)

{

return ts & (ThreadState.Unstarted |

ThreadState.WaitSleepJoin |

ThreadState.Stopped);

}

剩余124页未读，继续阅读

zuocanming

粉丝: 3
资源: 10

.NET 4.0 C# 线程深度解析

Threading in C#中文.7z

Threading in C# 中文版

Threading in C#(中).pdf

如何在C#中使用锁和计时器实现线程同步，以确保共享资源的安全访问？请提供代码示例。

在C#中如何利用线程同步机制和计时器来确保共享资源的安全访问？请提供代码示例说明。

在C#中如何使用锁和计时器实现线程同步，并确保资源的安全访问？请结合代码示例进行解释。

C# 获取当前进程的所有线程System.Threading.Thread

windows ble蓝牙扫描C#代码

跨线程访问WinForm控件 c#

C# 线程池 使用例子

最新资源

C# 线程池使用例子