C#多线程编程入门与基本同步机制详解

需积分: 10 107 浏览量更新于2024-07-22 1 收藏 1.15MB PDF 举报

C#多线程资料是一份深入讲解C#编程中多线程概念和技术的经典英文书籍，作者是Joseph Albahari。该书于2006年至2010年期间发布，适合希望深入了解C#及其.NET框架下多线程编程的读者。作者在书中详细阐述了多线程的相关理论与实践，包括但不限于： 1. 入门与概念：介绍了多线程的基本概念，解释了线程和进程的区别，以及多线程在软件设计中的正确使用和潜在误用。 2. 线程创建与启动：说明如何在C#中创建新线程，并演示如何启动和控制线程的执行，包括如何传递数据给子线程、命名线程、区分前台和后台线程以及设置线程优先级。 3. 线程同步与协作：探讨了同步机制的重要性，如阻塞、非阻塞（即"Spinning"）和线程状态管理。作者还讲解了锁定（Locking）的概念，使用Monitor.Enter和Monitor.Exit进行线程同步，以及选择合适的同步对象策略。 4. 死锁分析与避免：讨论了死锁的概念，以及如何识别和避免线程间的循环等待问题，确保程序的正常运行。 5. 线程池优化：讲解了.NET框架中的线程池技术，包括如何通过Task Parallel Library (TPL) 和传统方式进入线程池，以及如何优化线程池性能。 6. 高级同步工具：介绍了Mutex（互斥量）和Semaphore（信号量）这两种常用的同步机制，帮助开发者在并发环境中实现更精细的控制。 7. 性能与效率：强调了线程同步对性能的影响，提供了一些建议来优化多线程应用程序，以平衡并发性和资源利用。该资源不仅适合初学者理解多线程基础，也对有一定经验的开发人员提供了深入学习和实践多线程编程的宝贵资料。通过阅读这本书，开发者可以掌握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页未读，继续阅读

冷尘

粉丝: 1
资源: 8

C#多线程编程入门与基本同步机制详解

c#多线程 资料

c# 多线程有用的资料

C# 多线程资料集合

C# 多线程 static

c# 多线程学习路线

深入浅出讲解c#多线程

c# 多线程task

C# 多线程实现方式

c# 多线程下载文件

python的多线程与C#多线程的区别

最新资源

c#多线程资料