异步编程：轻量级线程同步基元对象

 

         从此图中我们会发现 .NET 与C# 的每个版本发布都是有一个“主题”。即：C#1.0托管代码→C#2.0泛型→C#3.0LINQ→C#4.0动态语言→C#5.0异步编程。现在我为最新版本的“异步编程”主题写系列分享，期待你的查看及点评。

 

传送门：异步编程系列目录……

 

开始《异步编程：同步基元对象（下）》

示例：异步编程：轻量级线程同步基元对象.rar

         在《异步编程：线程同步基元对象》中我介绍了.NET4.0之前为我们提供的各种同步基元（包括Interlocked、Monitor\lock、EventWaitHandle、Mutex、Semaphore等），随着.NET框架的进化，.NET4.0|.NET4.5又为我们带来了更多优化的同步基元选择。这当然不是告诉我们完全放弃.NET4.0之前所提供的同步基元，只是需要我们“因地制宜”。那我们如何判断适合使用哪种同步基元结构呢，就需要我们对各种同步基元有个本质的理解和清楚.NET所做的优化本质是什么。

 

基元用户模式构造、基元内核模式构造、混合构造

基元线程同步构造分为：基元用户模式构造和基元内核模式构造。

1.         基元用户模式构造

应尽量使用基元用户模式构造，因为它们使用特殊的CPU指令来协调线程，这种协调发生硬件中，速度很快。但也因此Windows操作系统永远检测不到一个线程在一个用户模式构造上阻塞了，这种检测不到有利有弊：

1)         利：因为用户模式构造上阻塞的一个线程，池线程永远不认为已经阻塞，所以不会出现“线程池根据CPU使用情况误判创建更多的线程以便执行其他任务，然而新创建的线程也可能因请求的共享资源而被阻塞，恶性循环，徒增线程上下文切换的次数”的问题。

2)         弊：当你想要取得一个资源但又短时间取不到时，一个线程会一直在用户模式中运行，造成CPU资源的浪费，此时我们更希望像内核模式那样停止一个线程的运行让出CPU。

在《异步编程：线程同步基元对象》中包含的用户模式构造有：volatile关键字、Interlocked静态类、Thread的VolatileWrite()与VolatileRead()方法。

2.         基元内核模式构造

是Windows操作系统自身提供的。它们要求我们调用在操作系统内核中实现的函数，调用线程将从托管代码转换为本地用户模式代码，再转换为本地内核模式代码，然后还要朝相反的方向一路返回，会浪费大量CPU时间，同时还伴随着线程上下文切换，因此尽量不要让线程从用户模式转到内核模式。

内核模式的构造具有基元用户模式构造所不具有的一些优点：

1)         一个内核模式的构造检测到在一个资源上的竞争时，Windows会阻塞输掉的线程，使它不占着一个CPU“自旋”，无谓地浪费处理器资源。

2)         内核模式的构造可实现本地和托管线程相互之间的同步。

3)         内核模式的构造可同步在一台机器的不同进程中运行的线程。

4)         内核模式的构造可应用安全性设置，防止未经授权的帐户访问它们。

5)         一个线程可一直阻塞，直到一个集合中的所有内核模式的构造都可用，或者直到一个集合中的任何一个内核模式的构造可用。

6)         在内核模式的构造上阻塞的一个线程可以指定一个超时值；如果在指定的时间内访问不到希望的资源，线程可以解除阻塞并执行其他任务。

在《异步编程：线程同步基元对象》中包含的内核模式构造有：EventWaitHandle(以及AutoResetEvent与ManualResetEvent)、Mutex、Semaphore。（另外：ReaderWriterLock）

3.         混合构造

对于在一个构造上等待的线程，如果拥有这个构造的线程一直不释放它，则会出现：

1)         如果是用户模式构造，则线程将一直占用CPU，我们称之为“活锁”。

2)         如果是内核模式构造，则线程将一直被阻塞，我们称之为“死锁”。

然后两者之间，死锁总是优于活锁，因为活锁既浪费CPU时间，又浪费内存。而死锁只浪费内存。

混合构造正是为了解决这种场景。其通过合并用户模式和内核模式实现：在没有线程竞争的时候，混合构造提供了基元用户模式构造所具有的性能优势。多个线程同时竞争一个构造的时候，混合构造则使用基元内核模式的构造来提供不“自旋”的优势。由于在大多数应用程序中，线程都很少同时竞争一个构造，所以在性能上的增强可以使你的应用程序表现得更出色。

混合结构优化的本质：两阶段等待操作

线程上下文切换需要花费几千个周期(每当线程等待内核事件WaitHandle时都会发生)。我们暂且称其为C。假如线程所等待的时间小于2C(1C用于等待自身，1C用于唤醒)，则自旋等待可以降低等待所造成的系统开销和滞后时间，从而提升算法的整体吞吐量和可伸缩性。

在多核计算机上，当预计资源不会保留很长一段时间时，如果让等待线程以用户模式旋转数十或数百个周期，然后重新尝试获取资源，则效率会更高。如果在旋转后资源变为可用的，则可以节省数千个周期。如果资源仍然不可用，则只花费了少量周期，并且仍然可以进行基于内核的等待。这一旋转-等待的组合称为“两阶段等待操作”。

         在《异步编程：线程同步基元对象》中包含的有：Monitor\lock；

本节将给大家介绍.NET4.0中加入的混合结构：ManualResetEventSlim、SemaphoreSlim、CountdownEvent、Barrier、ReaderWriterLockSlim。

 

        另外：看到园友写了篇《理解Windows内核模式与用户模式》，讲的是内核架构及用户模式调用内核模式方式。

 

在介绍.NET4.0新同步结构前，我们需要：

1)         认识两个协作对象：CancellationTokenSource和cancellationToken。因为它们常常被用于混合结构中。Eg：使一个线程强迫解除其构造上的等待阻塞。

2)         认识两个自旋结构：SpinWait和SpinLock

 

协作式取消

         对于长时间运行的计算限制操作来说，支持取消是一件很“棒”的事情。.NET 4.0提供了一个标准的取消操作模式。即通过使用CancellationTokenSource创建一个或多个取消标记CancellationToken（cancellationToken可在线程池中线程或 Task 对象之间实现协作取消），然后将此取消标记传递给应接收取消通知的任意数量的线程或Task对象。当调用CancellationToken关联的CancellationTokenSource对象的 Cancle()时，每个取消标记(CancellationToken)上的IsCancellationRequested属性将返回true。异步操作中可以通过检查此属性做出任何适当响应。

1.         CancellationTokenSource相关API：

    // 通知System.Threading.CancellationToken，告知其应被取消。
    public class CancellationTokenSource : IDisposable
    {
        // 构造一个CancellationTokenSource将在指定的时间跨度后取消。
        public CancellationTokenSource(int millisecondsDelay);

        // 获取是否已请求取消此CancellationTokenSource。
        public bool IsCancellationRequested { get; }
        
        // 获取与此CancellationTokenSource关联的CancellationToken。
        public CancellationToken Token { get; }

        // 传达取消请求。参数throwOnFirstException:指定异常是否应立即传播。
        public void Cancel();
        public void Cancel(bool throwOnFirstException);
        // 在此CancellationTokenSource上等待指定时间后“取消”操作。
        public void CancelAfter(int millisecondsDelay);

        // 创建一组CancellationToken关联的CancellationTokenSource。
        public static CancellationTokenSource CreateLinkedTokenSource(paramsCancellationToken[] tokens);

        // 释放由CancellationTokenSource类的当前实例占用的所有资源。
        public void Dispose();
        ……
    }

分析：

1)         CancellationTokenSource.CreateLinkedTokenSource()方法

将一组CancellationToken连接起来并创建一个新的CancellationTokenSource。任何一个CancellationToken对应的旧CancellationTokenSource被取消，这个新的CancellationTokenSource对象也会被取消。

原理：创建一个新的CancellationTokenSource实例，并将该实例的Cancel()委托分别传递给这组CancellationToken实例的Register()方法，然后返回新创建的CancellationTokenSource实例。

2)         CancellationTokenSource实例Cancel()方法做了什么：

a)         将CancellationTokenSource实例的IsCancellationRequested属性设置为true。CancellationToken实例的IsCancellationRequested属性是调用CancellationTokenSource实例的IsCancellationRequested属性。

b)         调用CancellationTokenSource实例的CreateLinkedTokenSource()注册的Cancel()委托回调；

c)         调用CancellationToken实例的Register()注册的回调；

d)         处理回调异常。（参数throwOnFirstException）

                                       i.              若为Cancel()传递true参数，那么抛出了未处理异常的第一个回调方法会阻止其他回调方法的执行，异常会立即从Cancel()中抛出；

                                      ii.              若为Cancel()传递false（默认为false），那么登记的所有回调方法都会调用。所有未处理的异常都会封装到一个AggregateException对象中待回调都执行完后返回，其InnerExceptions属性包含了所有异常的详细信息。

        e)    给CancellationToken对象的ManualResetEvent对象Set()信号。

2.         CancellationToken相关API

    // 传播有关应取消操作的通知。
    public struct CancellationToken
    {
        public CancellationToken(bool canceled);
        public static CancellationToken None { get; }

        // 获取此标记是否能处于已取消状态。
        public bool CanBeCanceled { get; }
        // 获取是否已请求取消此标记。
        public bool IsCancellationRequested { get; }

        // 获取内部ManualResetEvent，在CancellationTokenSource执行Cancel()时收到set()通知。
        public WaitHandle WaitHandle{ get; }

        // 注册一个将在取消此CancellationToken时调用的委托。
        // 参数:useSynchronizationContext:
        //一个布尔值，该值指示是否捕获当前SynchronizationContext并在调用 callback 时使用它。
        public CancellationTokenRegistration Register(Action