简而言之,一个程序至少有一个进程,一个进程至少有一个线程.class="Apple-converted-space">
线程的划分尺度小于进程，使得多线程程序的并发性高。
另外，进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程序的运行效率。
线程在执行过程中与进程还是有区别的。每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制。
从逻辑角度来看，多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配。这就是进程和线程的重要区别。
进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动,进程是系统进行资源分配和调度的一个独立单位.
线程是进程的一个实体,是CPU调度和分派的基本单位,它是比进程更小的能独立运行的基本单位.线程自己基本上不拥有系统资源,只拥有一点在运行中必不可少的资源(如程序计数器,一组寄存器和栈),但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源.
一个线程可以创建和撤销另一个线程;同一个进程中的多个线程之间可以并发执行.
进程和线程的主要差别在于它们是不同的操作系统资源管理方式。进程有独立的地址空间，一个进程崩溃后，在保护模式下不会对其它进程产生影响，而线程只是一个进程中的不同执行路径。线程有自己的堆栈和局部变量，但线程之间没有单独的地址空间，一个线程死掉就等于整个进程死掉，所以多进程的程序要比多线程的程序健壮，但在进程切换时，耗费资源较大，效率要差一些。但对于一些要求同时进行并且又要共享某些变量的并发操作，只能用线程，不能用进程。如果有兴趣深入的话，我建议你们看看《现代操作系统》或者《操作系统的设计与实现》。对就个问题说得比较清楚。
进程（process）是一块包含了某些资源的内存区域。操作系统利用进程把它的工作划分为一些功能单元。
进程中所包含的一个或多个执行单元称为线程（thread）。进程还拥有一个私有的虚拟地址空间，该空间仅能被它所包含的线程访问。
当运行.NET程序时，进程还会把被称为CLR的软件层包含到它的内存空间中。上一章曾经对CLR做了详细描述。该软件层是在进程创建期间由运行时宿主载入的（参见4.2.3节）。
线程只能归属于一个进程并且它只能访问该进程所拥有的资源。当操作系统创建一个进程后，该进程会自动申请一个名为主线程或首要线程的线程。主线程将执行运行时宿主, 而运行时宿主会负责载入CLR。
应用程序（application）是由一个或多个相互协作的进程组成的。例如，Visual Studio开发环境就是利用一个进程编辑源文件，并利用另一个进程完成编译工作的应用程序。
在Windows NT/2000/XP操作系统下，我们可以通过任务管理器在任意时间查看所有的应用程序和进程。尽管只打开了几个应用程序，但是通常情况下将有大约30个进程同时运行。 事实上，为了管理当前的会话和任务栏以及其他一些任务，系统执行了大量的进程。
在运行于32位处理器上的32位Windows操作系统中，可将一个进程视为一段大小为4GB（232字节）的线性内存空间，它起始于0x00000000结束于0xFFFFFFFF。这段内存空间不能被其他进程所访问，所以称为该进程的私有空间。这段空间被平分为两块，2GB被系统所有，剩下2GB被用户所有。
如果有N个进程运行在同一台机器上，那么将需要N×4GB的海量RAM，还好事实并非如此。
System.Diagnostics.Process类的实例可以引用一个进程，被引用的进程包含以下几种。
通过该类所包含的方法和字段，可以创建或销毁一个进程，并且可以获得一个进程的相关信息。下面将讨论一些使用该类实现的常见任务。
5.2.3 创建和销毁子进程
下面的程序创建了一个称为子进程的新进程。在这种情况下，初始的进程称为父进程。子进程启动了一个记事本应用程序。父进程的线程在等待1秒后销毁该子进程。该程序的执行效果就是打开并关闭记事本。
例5-1
静态方法Start()可以使用已存在的Windows文件扩展名关联机制。例如，我们可以利用下面的代码执行同样的操作。
默认情况下，子进程将继承其父进程的安全上下文。但还可以使用Process.Start()方法的一个重载版本在任意用户的安全上下文中启动该子进程，当然需要通过一个System.Diagnostics. ProcessStartInfo类的实例来提供该用户的用户名和密码。
有些应用程序需要这种功能。实际上，通常来说在同一台机器上同时运行一个应用程序的多个实例并没有意义。
直到现在，为了在Windows下满足上述约束，开发者最常用的方法仍然是使用有名互斥体（named mutex）技术（参见5.7.2节）。然而采用这种技术来满足上述约束存在以下缺点：
幸而在System.Diagnostics.Process类中拥有GetCurrentProcess()（返回当前进程）和GetPro- cesses()（返回机器上所有的进程）这样的静态方法。在下面的程序中我们为上述问题找到了一个优雅且简单的解决方案。
例5-2
通过方法参数指定了远程机器的名字后，GetProcesses()方法也可以返回远程机器上所有的进程。
可以调用System.Environment类中的静态方法Exit(int exitCode)或FailFast(stringmessage)终止当前进程。Exit()方法是最好的选择，它将彻底终止进程并向操作系统返回指定的退出代码值。之所以称为彻底终止是因为当前对象的所有清理工作以及finally块的执行都将由不同的线程完成。当然，终止进程将花费一定的时间。
顾名思义，FailFast()方法可以迅速终止进程。Exit()方法所做的预防措施将被它忽略。只有一个包含了指定信息的严重错误会被操作系统记录到日志中。你可能想要在探查问题的时候使用该方法，因为可以将该程序的彻底终止视为数据恶化的起因。
一个线程包含以下内容。
所有这些元素都归于线程执行上下文的名下。处在同一个进程中的所有线程都可以访问该进程所包含的地址空间，当然也包含存储在该空间中的所有资源。
我们不准备讨论线程在内核模式或者用户模式执行的问题。尽管.NET以前的Windows一直使用这两种模式，并且依然存在，但是对.NET Framework来说它们是不可见的。
并行使用一些线程通常是我们在实现算法时的自然反应。实际上，一个算法往往由一系列可以并发执行的任务组成。但是需要引起注意的是，使用大量的线程将引起过多的上下文切换，最终反而影响了性能。
同样，几年前我们就注意到，预测每18个月处理器运算速度增加一倍的摩尔定律已不再成立。处理器的频率停滞在3GHz~4GHz上下。这是由于物理上的限制，需要一段时间才能取得突破。同时，为了在性能竞争中不会落败，较大的处理器制造商如AMD和Intel目前都将目标转向多核芯片。因此我们可以预计在接下去的几年中这种类型的架构将广泛被采用。在这种情况下，改进应用性能的唯一方案就是合理地利用多线程技术。
必须要了解，执行.NET应用的线程实际上仍然是Windows线程。但是，当某个线程被CLR所知时，我们将它称为受托管的线程。具体来说，由受托管的代码创建出来的线程就是受托管的线程。如果一个线程由非托管的代码所创建，那么它就是非托管的线程。不过，一旦该线程执行了受托管的代码它就变成了受托管的线程。
一个受托管的线程和非托管的线程的区别在于，CLR将创建一个System.Threading.Thread类的实例来代表并操作前者。在内部实现中，CLR将一个包含了所有受托管线程的列表保存在一个叫做ThreadStore地方。
CLR确保每一个受托管的线程在任意时刻都在一个AppDomain中执行，但是这并不代表一个线程将永远处在一个AppDomain中，它可以随着时间的推移转到其他的AppDomain中。关于AppDomain的概念参见4.1。
从安全的角度来看，一个受托管的线程的主用户与底层的非托管线程中的Windows主用户是无关的。
我们可以问自己下面这个问题: 我的计算机只有一个处理器，然而在任务管理器中我们却可以看到数以百计的线程正同时运行在机器上！这怎么可能呢？
多亏了抢占式多任务处理，通过它对线程的调度，使得上述问题成为可能。调度器作为Windows内核的一部分，将时间切片，分成一段段的时间片。这些时间间隔以毫秒为精度且长度并不固定。针对每个处理器，每个时间片仅服务于单独一个线程。线程的迅速执行给我们造成了它们在同时运行的假象。我们在两个时间片的间隔中进行上下文切换。该方法的优点在于，那些正在等待某些Windows资源的线程将不会浪费时间片，直到资源有效为止。
之所以用抢占式这个形容词来修饰这种多任务管理方式，是因为在此种方式下线程将被系统强制性中断。那些对此比较好奇的人应该了解到，在上下文切换的过程中，操作系统会在下一个线程将要执行的代码中插入一条跳转到下一个上下文切换的指令。该指令是一个软中断，如果线程在遇到这条指令前就终止了（例如，它正在等待某个资源），那么该指定将被删除而上下文切换也将提前发生。
抢占式多任务处理的主要缺点在于，必须使用一种同步机制来保护资源以避免它们被无序访问。除此之外，还有另一种多任务管理模型，被称为协调式多任务管理，其中线程间的切换将由线程自己负责完成。该模型普遍认为太过危险，原因在于线程间的切换不发生的风险太大。如我们在4.2.8节中所解释的那样，该机制会在内部使用以提升某些服务器的性能，例如SQL Server2005。但Windows操作系统仅仅实现了抢占式多任务处理。
某些任务拥有比其他任务更高的优先级，它们需要操作系统为它们申请更多的处理时间。例如，某些由主处理器负责的外围驱动器必须不能被中断。另一类高优先级的任务就是图形用户界面。事实上，用户不喜欢等待用户界面被重绘。
那些从Win32世界来的用户知道在CLR的底层，也就是Windows操作系统中，可以为每个线程赋予一个0~31的优先级。但你无法在.NET的世界中也使用这些数值，因为：
1. 进程的优先级
可以使用Process类中的类型为ProcessPriorityClass的PriorityClass{get;set;}属性为进程赋予一个优先级。System.Diagnostics.ProcessPriorityClass枚举包含以下值：
如果某个进程中属于Process类的PriorityBoostEnabled属性的值为true（默认值为true），那么当该进程占据前台窗口的时候，它的优先级将增加一个单位。只有当Process类的实例引用的是本机进程时，才能够访问该属性。
可以通过以下操作利用任务管理器来改变一个进程的优先级：在所选的进程上点击右键>设置优先级>从提供的6个值（和上图所述一致）中做出选择。
Windows操作系统有一个优先级为0的空闲进程。该进程不能被其他任何进程使用。根据定义，进程的活跃度用时间的百分比表示为：100%减去在空闲进程中所耗费时间的比率。
2. 线程的优先级
每个线程可以结合它所属进程的优先级，并使用System.Threading.Thread类中类型为ThreadPriority的Priority{get;set;}属性定义各自的优先级。System.Threading.Thread- Priority包含以下枚举值：
在大多数应用程序中，不需要修改进程和线程的优先级，它们的默认值为Normal。
CLR会自动将一个System.Threading.Thread类的实例与各个受托管的线程关联起来。可以使用该对象从线程自身或从其他线程来操纵线程。还可以通过System.Threading.Thread类的静态属性CurrentThread来获得当前线程的对象。
Thread类有一个功能使我们能够很方便的调试多线程应用程序，该功能允许我们使用一个字符串为线程命名：
只需通过创建一个Thread类的实例，就可以在当前的进程中创建一个新的线程。该类拥有多个构造函数，它们将接受一个类型为System.Threading.ThreadStart或System.Threading.Parame-trizedThreadStart的委托对象作为参数，线程被创建出来后首先执行该委托对象所引用的方法。使用ParametrizedThreadStart类型的委托对象允许用户为新线程将要执行的方法传入一个对象作为参数。Thread类的一些构造函数还接受一个整型参数用于设置线程要使用的最大栈的大小，该值至少为128KB（即131072字节）。创建了Thread类型的实例后，必须调用Thread.Start()方法以真正启动这个线程。
例5-3
该程序输出：
在这个例子中，我们使用Join()方法挂起当前线程，直到调用Join()方法的线程执行完毕。该方法还存在包含参数的重载版本，其中的参数用于指定等待线程结束的最长时间（即超时）所花费的毫秒数。如果线程中的工作在规定的超时时段内结束，该版本的Join()方法将返回一个布尔量True。
可以使用Thread类的Sleep()方法将一个正在执行的线程挂起一段特定的时间，还可以通过一个以毫秒为单位的整型值或者一个System.TimeSpan结构的实例设定这段挂起的时间。该结构的一个实例可以设定一个精度为1/10 ms（100ns）的时间段，但是Sleep()方法的最高精度只有1ms。
我们也可以从将要挂起的线程自身或者另一个线程中使用Thread类的Suspend()方法将一个线程的活动挂起。在这两种情况中，线程都将被阻塞直到另一个线程调用了Resume()方法。相对于Sleep()方法，Suspend()方法不会立即将线程挂起，而是在线程到达下一个安全点之后，CLR才会将该线程挂起。安全点的概念参见4.7.11节。
5.3.8 终止一个线程
一个线程可以在以下场景中将自己终止。
第一种情况不太重要，我们将主要关注另两种情况。在这两种情况中，都可以使用Abort()方法（通过当前线程或从当前线程之外的一个线程）。使用该方法将在线程中引发一个类型为ThreadAbortException的异常。由于线程正处于一种被称为AbortRequested的特殊状态，该异常具有一个特殊之处：当它被异常处理所捕获后，将自动被重新抛出。只有在异常处理中调用Thread.ResetAbort()这个静态方法（如果我们有足够的权限）才能阻止它的传播。
例5-4 主线程的自杀
当线程A对线程B调用了Abort()方法，建议调用B的Join()方法，让A一直等待直到B终止。Interrupt()方法也可以将一个处于阻塞状态的线程（即由于调用了Wait()、Sleep()或者Join()其中一个方法而阻塞）终止。该方法会根据要被终止的线程是否处于阻塞状态而表现出不同的行为。
Thread类提供了IsBackground{get;set}的布尔属性。当前台线程还在运行时，它会阻止进程被终止。另一方面，一旦所指的进程中不再有前台线程，后台线程就会被CLR自动终止（调用Abort()方法）。IsBackground的默认值为false，这意味着所有的线程默认情况处于前台状态。
Thread类拥有一个System.Threading.ThreadState枚举类型的字段ThreadState，它包含以下枚举值：
有关每个状态的具体描述可以在MSDN上一篇名为“ThreadStateEnumeration”的文章中找到。该枚举类型是一个二进制位域，这表示一个该类型的实例可以同时表示多个枚举值。例如，一个线程可以同时处于Running、AbortRequested和Background这三种状态。二进制位域的概念参见10.11.3节。
根据我们在前面的章节中所了解的知识，我们定义了如图5-1所示的简化的状态图。
图5-1 简化的托管线程状态图
在多线程应用（一个或多个处理器）的计算中会使用到同步这个词。实际上，这些应用程序的特点就是它们拥有多个执行单元，而这些单元在访问资源的时候可能会发生冲突。线程间会共享同步对象，而同步对象的目的在于能够阻塞一个或多个线程，直到另一个线程使得某个特定条件得到满足。
我们将看到，存在多种同步类与同步机制，每种制针对一个或一些特定的需求。如果要利用同步构建一个复杂的多线程应用程序，那么很有必要先掌握本章的内容。我们将在下面的内容中尽力区分他们，尤其要指出那些在各个机制间最微妙的区别。
合理地同步一个程序是最精细的软件开发任务之一，单这一个主题就足以写几本书。在深入到细节之前，应该首先确认使用同步是否不可避免。通常，使用一些简单的规则可以让我们远离同步问题。在这些规则中有线程与资源的亲缘性规则，我们将在稍后介绍。
应该意识到，对程序中资源的访问进行同步时，其难点来自于是使用细粒度锁还是粗粒度锁这个两难的选择。如果在访问资源时采用粗粒度的同步方式，虽然可以简化代码但是也会把自己暴露在争用瓶颈的问题上。如果粒度过细，代码又会变的很复杂，以至于维护工作令人生厌。然后又会遇上死锁和竞态条件这些在下面章节将要介绍的问题。
因此在我们开始谈论有关同步机制之前，有必要先了解一下有关竞态条件和死锁的概念。
5.4.1 竞态条件
竞态条件指的是一种特殊的情况，在这种情况下各个执行单元以一种没有逻辑的顺序执行动作，从而导致意想不到的结果。
举一个例子，线程T修改资源R后，释放了它对R的写访问权，之后又重新夺回R的读访问权再使用它，并以为它的状态仍然保持在它释放它之后的状态。但是在写访问权释放后到重新夺回读访问权的这段时间间隔中，可能另一个线程已经修改了R的状态。
另一个经典的竞态条件的例子就是生产者/消费者模型。生产者通常使用同一个物理内存空间保存被生产的信息。一般说来，我们不会忘记在生产者与消费者的并发访问之间保护这个空间。容易被我们忘记的是生产者必须确保在生产新信息前，旧的信息已被消费者所读取。如果我们没有采取相应的预防措施，我们将面临生产的信息从未被消费的危险。
如果静态条件没有被妥善的管理，将导致安全系统的漏洞。同一个应用程序的另一个实例很可能会引发一系列开发者所预计不到的事件。一般来说，必须对那种用于确认身份鉴别结果的布尔量的写访问做最完善的保护。如果没有这么做，那么在它的状态被身份鉴别机制设置后，到它被读取以保护对资源的访问的这段时间内，很有可能已经被修改了。已知的安全漏洞很多都归咎于对静态条件不恰当的管理。其中之一甚至影响了Unix操作系统的内核。
死锁指的是由于两个或多个执行单元之间相互等待对方结束而引起阻塞的情况。例如：
一个线程T1获得了对资源R1的访问权。
一个线程T2获得了对资源R2的访问权。
T1请求对R2的访问权但是由于此权力被T2所占而不得不等待。
T2请求对R1的访问权但是由于此权力被T1所占而不得不等待。
T1和T2将永远维持等待状态，此时我们陷入了死锁的处境！这种问题比你所遇到的大多数的bug都要隐秘，针对此问题主要有三种解决方案：
前两种技术效率更高但是也更加难于实现。事实上，它们都需要很强的约束，而这点随着应用程序的演变将越来越难以维护。尽管如此，使用这些技术不会存在失败的情况。
大的项目通常使用第三种方法。事实上，如果项目很大，一般来说它会使用大量的资源。在这种情况下，资源之间发生冲突的概率很低，也就意味着失败的情况会比较罕见。我们认为这是一种乐观的方法。秉着同样的精神，我们在19.5节描述了一种乐观的数据库访问模型。
volatile字段可以被多个线程访问。我们假设这些访问没有做任何同步。在这种情况下，CLR中一些用于管理代码和内存的内部机制将负责同步工作，但是此时不能确保对该字段读访问总能读取到最新的值，而声明为volatile的字段则能提供这样的保证。在C#中，如果一个字段在它的声明前使用了volatile关键字，则该字段被声明为volatile。
不是所有的字段都可以成为volatile，成为这种类型的字段有一个条件。如果一个字段要成为volatile，它的类型必须是以下所列的类型中的一种：
你可能已经注意到了，只有值或者引用的位数不超过本机整型值的位数（4或8由底层处理器决定）的类型才能成为volatile。这意味着对更大的值类型进行并发访问必须进行同步，下面我们将会对此进行讨论。
经验显示，那些需要在多线程情况下被保护的资源通常是整型值，而这些被共享的整型值最常见的操作就是增加/减少以及相加。.NETFramework利用System.Threading.Interlocked类提供了一个专门的机制用于完成这些特定的操作。这个类提供了Increment()、Decrement()与Add()三个静态方法，分别用于对int或者long类型变量的递增、递减与相加操作，这些变量以引用方式作为参数传入。我们认为使用Interlocked类让这些操作具有了原子性。
下面的程序显示了两个线程如何并发访问一个名为counter的整型变量。一个线程将其递增5次，另一个将其递减5次。
例5-5
该程序输出（以非确定方式输出，意味着每执行一次显示的结果都是不同的）：
如果我们不让这些线程在每次修改变量后休眠10毫秒，那么它们将有足够的时间在一个时间片中完成它们的任务，那样也就不会出现交叉操作，更不用说并发访问了。
Interlocked类还允许使用Exchange()静态方法，以原子操作的形式交换某些变量的状态。还可以使用CompareExchange()静态方法在满足一个特定条件的基础上以原子操作的形式交换两个值。
以原子操作的方式完成简单的操作无疑是很重要的，但是这还远不能涵盖所有需要用到同步的事例。System.Threading.Monitor类几乎允许将任意一段代码设置为在某个时间仅能被一个线程执行。我们将这段代码称之为临界区。
Monitor类提供了Enter(object)与Exit(object)这两个静态方法。这两个方法以一个对象作为参数，该对象提供了一个简单的方式用于唯一标识那个将以同步方式访问的资源。当一个线程调用了Enter()方法，它将等待以获得访问该引用对象的独占权（仅当另一个线程拥有该权力的时候它才会等待）。一旦该权力被获得并使用，线程可以对同一个对象调用Exit()方法以释放该权力。
一个线程可以对同一个对象多次调用Enter()，只要对同一对象调用相同次数的Exit()来释放独占访问权。
一个线程也可以在同一时间拥有多个对象的独占权，但是这样会产生死锁的情况。
绝不能对一个值类型的实例调用Enter()与Exit()方法。
不管发生了什么，必须在finally子句中调用Exit()以释放所有的独占访问权。
如果在例5-5中，一个线程非要将counter做一次平方而另一个线程非要将counter乘2，我们就不得不用Monitor类去替换对Interlocked类的使用。f1()与f2()的代码将变成下面这样：
例5-6[1]
人们很容易想到用counter来代替typeof(Program)，但是counter是一个值类型的静态成员。需要注意平方和倍增操作是不满足交换律的，所以counter的最终结果是非确定性的。
C#语言通过lock关键字提供了一种比使用Enter()和Exit()方法更加简洁的选择。我们的程序可以改写为下面这个样子：
例5-7
和for以及if关键字一样，如果被lock关键字定义的块仅包含一条指令，就不再需要花括号。我们可以再次改写为：
使用lock关键字将引导C#编译器创建出相应的try/finally块，这样仍旧可以预期到任何可能引发的异常。可以使用Reflector或者ildasm.exe工具验证这一点。
和前面的例子一样，我们通常在一个静态方法中使用Monitor类配合一个Type类的实例。同样，我们往往会在一个非静态方法中使用this关键字来实现同步。在两种情况下，我们都是通过一个在类外部可见的对象对自身进行同步。如果其他部分的代码也利用这些对象来实现自身的同步，就会出现问题。为了避免这种潜在的问题，我们推荐使用一个类型为object的名为SyncRoot的私有成员，至于该成员是静态的还是非静态的则由需要而定。
例5-8
System.Collections.ICollection接口提供了object类型的SyncRoot{get;}属性。大多数的集合类（泛型或非泛型）都实现了该接口。同样地，可以使用该属性同步对集合中元素的访问。不过在这里SyncRoot模式并没有被真正的应用，因为我们对访问进行同步所使用对象不是私有的。
例5-9
若一个类的每个实例在同一时间不能被一个以上的线程所访问，则该类称之为一个线程安全的类。为了创建一个线程安全的类，只需将我们见过的SyncRoot模式应用于它所包含的方法。如果一个类想变成线程安全的，而又不想为类中代码增加过多负担，那么有一个好方法就是像下面这样为其提供一个经过线程安全包装的继承类。
例5-10
另一种方法就是使用System.Runtime.Remoting.Contexts.SynchronizationAttribute，这点我们将在本章稍后讨论。
该方法与Enter()相似，只不过它是非阻塞的。如果资源的独占访问权已经被另一个线程占据，该方法将立即返回一个false返回值。我们也可以调用TryEnter()方法，让它以毫秒为单位阻塞一段有限的时间。因为该方法的返回结果并不确定，并且当获得独占访问权后必须在finally子句中释放该权力，所以建议当TryEnter()失败时立即退出正在调用的函数：
例5-11[2]
Wait()、Pulse()与PulseAll()方法必须在一起使用并且需要结合一个小场景才能被正确理解。我们的想法是这样的：一个线程获得了某个对象的独占访问权，而它决定等待（通过调用Wait()）直到该对象的状态发生变化。为此，该线程必须暂时失去对象独占访问权，以便让另一个线程修改对象的状态。修改对象状态的线程必须使用Pulse()方法通知那个等待线程修改完成。下面有一个小场景具体说明了这一情况。
如果Wait(OBJ)被一个调用了多次Enter(OBJ)的线程所调用，那么该线程将需要调用相同次数的Exit(OBJ)以释放对OBJ的访问权。即使在这种情况下，另一个线程调用一次Pulse(OBJ)就足以将第一个线程变成非阻塞态。
下面的程序通过ping与pong两个线程以交替的方式使用一个ball对象的访问权来演示该功能。
例5-12
该程序输出（以不确定的方式）：
pong线程没有结束并且仍然阻塞在Wait()方法上。由于pong线程是第二个获得ball对象的独占访问权的，所以才导致了该结果。
相关文章
