C#异步编程（四）混合模式线程同步

　　之前讨论了基元用户模式和内核模式线程同步构造。其他所有线程同步构造都基于它们，而且一般都合并了用户模式和内核模式构造，我们称为混合线程同步构造。没有线程竞争时，混合构造提供了基元用户模式构造所具有的性能优势。多个线程竞争一个构造时，混合构造通过基元内核模式的构造来提供不自旋的优势。由于大多数应用程序的线程都很少同时竞争一个构造，所以性能上的增强可以使你的应用程序表现得更出色。

本章最后展示如何使用fcl的并发集合类来取代混合构造，从而最小化资源使用并提升性能。同时还讨论了异步的同步构造，允许以同步方式访问资源，同时不造成任何线程的阻塞，从而减少资源消耗，并提高了伸缩性。

一个简单的混合锁

internal sealed class SimpleHybridLock:IDisposable
{
    //int由基元用户模式构造（interlocked的方法）使用
    private Int32 m_waiters = ;

    //autoResetEvent基元内核模式构造
    private AutoResetEvent m_waiterLock = new AutoResetEvent(false);

    private void Enter()
    {
        //指出这个线程想要获得锁
        if (Interlocked.Increment(ref m_waiters) ==)
        {
            return;//锁可以使用，无竞争，直接返回
        }
        //另一个线程用有锁（发送竞争），使这个线程等待
        m_waiterLock.WaitOne();//这里产生性能消耗，但是也比自旋要好（当然也存在自旋几毫秒就获得锁的情况。。。。）
        //waitone返回后，这个线程拿到了锁
    }
    public void Leave()
    {
        //这个线程准备释放锁
        if (Interlocked.Decrement(ref m_waiters)==)
        {
            return;
        }
        //其他线程正在阻塞，唤醒其中一个
        m_waiterLock.Set();

    }
    public void Dispose()
    {
        m_waiterLock.Dispose();
    }
}

　　SimpleHybridLock包含两字字段：一个int32，由基元用户模式的构造来操作；以及一个AutoResetEvent，他是一个基元内核模式的构造。为了获得出色的性能，锁要尽量操作int32，尽量少操作AutoResetEvent。也有出现竞争情况才去创建AutoResetEvent的设计，后面的示例代码也有这种设计。

　　在实际应用中，任何线程都可以在任何时候调用leave方法，因为enter并没有记录哪个线程获得了锁。虽然可以添加字段和代码维护这个信息，但是会增大内存开销而且影响enter和leave的性能，我情愿有一个性能高超的锁，并确保我的代码以正确的方式使用它。你会注意到，事件和信号量都没有维护这种信息，只有互斥体才有维护。

自旋、线程所有权和递归

　　由于转换为内核模式会造成巨大的性能损失，而且线程占有锁的时间通常很短，所以为了提升应用的总体性能，可以让一个线程在用户模式自旋一小段时间，再让线程转换为内核模式。如果线程正在等待的锁在自旋期间变得可用，就能避免模式转换了。

此外，有的锁限制只能由获得锁的线程释放锁，有的锁允许递归，所以可以通过一些逻辑支持自旋、线程所有权和递归，下面是一个例子：

internal sealed class AnotherHybridLock:IDisposable
{
    //int由基元用户模式构造（interlocked的方法）使用
    private Int32 m_waiters = ;

    //autoResetEvent基元内核模式构造
    private AutoResetEvent m_waiterLock = new AutoResetEvent(false);

    //这个字段控制自旋，希望能提升性能
    private Int32 m_spincount = ;
    //这些字段指出哪个线程拥有锁，以及拥有了多少次
    private Int32 m_owingThreadId=,m_recursion=;
    private void Enter()
    {
        //如果调用线程已经拥有锁，递增递归计数并返回
        Int32 threadId = Thread.CurrentThread.ManagedThreadId;
        if (threadId==m_owingThreadId)
        {
            m_recursion++;return;
        }
        //调用线程不拥有锁，尝试获取他
        SpinWait spinwait = new SpinWait();
        for (int i = ; i < m_spincount; i++)
        {
            //锁国锁可以自由使用了，这个线程获取
            //比较location1与comparand，如果不相等，什么都不做；如果location1与comparand相等，则用value替换location1的值。无论比较结果相等与否，返回值都是location1中原有的值
            if (Interlocked.CompareExchange(ref m_waiters,,) == )
            {
                goto GotLock;
            }
            //黑科技：给其他线程运行的机会，希望锁会被释放
            spinwait.SpinOnce();
        }

        //自旋结束，再次尝试
        if (Interlocked.Increment(ref m_waiters) > )
        {
            //仍然是竞争状态，线程阻塞
            m_waiterLock.WaitOne();
            //等待结束之后，他拥有锁
        }
        GotLock:
        //一个线程获得锁时，记录他的id，并指出线程拥有锁一次
        m_owingThreadId = threadId;m_recursion = ;
    }
    public void Leave()
    {
        //这个线程准备释放锁
        if (Interlocked.Decrement(ref m_waiters) == )
        {
            return;
        }
        //其他线程正在阻塞，唤醒其中一个
        m_waiterLock.Set();

    }
    public void Dispose()
    {
        m_waiterLock.Dispose();
    }
}

改进的混合锁

执行结果

注意，anotherHybridLock的性能不如simpleHybridLock。这是因为需要额外的逻辑和错误检查来管理线程所有权和递归行为。

FCL中的混合构造

Fcl是framework class library的简称。

ManualResetEventSlim类和SemaphoreSlim类

这两个构造的工作方式和对应的内核模式完全一致，只是他们都在用户模式中自旋，而且都推迟到发生第一次竞争时，才创建内核模式的构造。这里就不多介绍了。

Monitor类和同步块

　　因为Monitor是资格最老的构造，所以用的比较多，但是存在一些问题。这个类是lock关键字使用的混合锁的类型。ConcurrentDictory里面对key进行的锁定也是使用这个构造。

堆中的每个对象都可关联一个名为同步块的数据结构。同步块包含字段，他为内核对象、线程id、递归计数以及等待线程计数提供了相应的字段。

monitor是静态类，他的方法接收任何堆对象的引用，这些方法对指定对象的同步块中的字段进行操作。

　　显然，为堆中每个对象都关联一个同步块数据结构显得浪费，尤其是大部分都从不使用。为了节省内存，clr团队采用一种更经济的方式提供刚才描述的功能。他的工作原理：clr初始化时在堆中分配一个同步块数组（每当一个对象在堆中创建的时候，都有两个额外开销的字段与它管理，第一个是“类型对象指针”另一个是“同步索引块”，包含同步块数组中的一个整数索引）。

一个对象在构造时，他的同步索引块初始化为-1，表明不引用任何同步块。然后调用monitor.Enter时，clr在数组中找到一个空白同步块，并设置对象的同步索引块，让他引用该同步块。调用exit时，会检查是否有其他线程正在等待使用对象的同步块。如果没有线程等待它，同步块就自由了，对象同步块索引设会-1。

monitor类使用方式如下：

internal sealed class MonitorTransaction
{
    private DateTime m_timeOfLastTrans;
    public void PerformTransaction()
    {
        Monitor.Enter(this);
        //以下代码拥有对数据的独占访问权
        m_timeOfLastTrans = DateTime.Now;
        Monitor.Exit(this);
    }
    public DateTime LastTransaction
    {
        get
        {
            Monitor.Enter(this);
            DateTime temp = m_timeOfLastTrans;
            Monitor.Exit(this);
            return temp;
        }
    }
}

monitor可能出现的问题：

　　每个对象的同步块索引都是隐式为公共的。因为你使用一个对象来进行Monitor.Enter(t)的时候，有可能t会被其他线程使用，如果这个线程也对t使用了一些会使用锁的操作，那么就会死锁，而且比较难判断究竟是哪里造成的死锁。

所以，最好的办法是坚持使用私有锁。私有锁是必要的，防止职责不清晰。

internal sealed class MonitorTransactionBetter
{
    private readonly object m_lock = new object();//现在每个transaction对象都有私有锁
    private DateTime m_timeOfLastTrans;
    public void PerformTransaction()
    {
        Monitor.Enter(m_lock);
        //以下代码拥有对数据的独占访问权
        m_timeOfLastTrans = DateTime.Now;
        Monitor.Exit(m_lock);
    }
    public DateTime LastTransaction
    {
        get
        {
            Monitor.Enter(m_lock);
            DateTime temp = m_timeOfLastTrans;
            Monitor.Exit(m_lock);
            return temp;
        }
    }
}

　　通过以上讨论，我们可以看出，monitor不应该实现成静态类；他应该像其他所有同步构造那样实现。

　　由于monitor的方法获取一个object，所以传递值类型会导致值类型装箱，造成线程在已装箱对象上获取锁。每次调用monitor.enter都会在一个完全不同的对象上获取锁，造成完全无法实现线程同步。

这也是为什么被锁的对象一定要使用引用类型。

　　还有一个问题，就是前面说过的lock关键字，这个关键字的使用相当于在代码的最后加上了一个finally，里面判断如果是锁定的状态，会自动退出锁。但是如果代码一旦在finally里更改状态出现异常，那么这个锁就处于损坏状态。还有一个问题，进入和离开try块会影响方法的性能。所以使用lock关键字并不是看上去的那么方便。

ReaderWriterLockSlim类

ReaderWriterLockSlim构造执行逻辑如下:

1、 一个线程向数据写入时，请求访问的其他所有线程都被阻塞。

2、 一个线程从数据读取时，请求读取的其他线程允许继续执行，但请求写入的线程仍被阻塞。

3、 向线程写入的线程结束后，要么解除一个写入线程的阻塞，那么解除所有读取线程的阻塞。如果没有线程阻塞，那么锁进入自由状态。

4、 所有读取的线程结束后，一个writer线程才会被解除阻塞。

下面展示了这个类

以下代码演示这个构造的用法

internal sealed class ReaderWriterTransation:IDisposable
{
    private readonly ReaderWriterLockSlim m_lock = new ReaderWriterLockSlim(LockRecursionPolicy.NoRecursion);

    private DateTime m_timeOfLastTrans;

    public void PerformTransaction()
    {
        m_lock.EnterWriteLock();
        m_timeOfLastTrans = DateTime.Now;
        m_lock.ExitWriteLock();
    }
    public DateTime LastTransaction
    {
        get {
            m_lock.EnterReadLock();
            DateTime temp = m_timeOfLastTrans;
            m_lock.ExitReadLock();
            return temp;
        }
    }
    public void Dispose() { m_lock.Dispose(); }
}

ReaderWriterLockSlim类提供了一些额外的方法，比如允许读线程升级为写线程，但如果去使用这个功能，性能会大打折扣。

线程同步构造小结

我的建议是，代码尽量不要阻塞任何线程。执行异步计算或I/O操作时，将数据从一个线程交给另一个线程时，应避免多个线程同时访问数据。如果不能完全做到这一点，请尽量使用Volatile和InterLocked的方法，因为他们速度很快，且绝不阻塞线程。遗憾的是，这些方法只能操作简单类型，但你可以像InterLocked Anything模式描述的那样执行丰富的操作。