C#异步编程(四)混合模式线程同步

时间:2022-05-14 19:31:00

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

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

一个简单的混合锁

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

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

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

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

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

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

自旋、线程所有权和递归

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

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

C#异步编程(四)混合模式线程同步C#异步编程(四)混合模式线程同步
internal sealed class AnotherHybridLock:IDisposable
{
    //int由基元用户模式构造(interlocked的方法)使用
    private Int32 m_waiters = 0;

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

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


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

    }
    public void Dispose()
    {
        m_waiterLock.Dispose();
    }
}
改进的混合锁

执行结果

C#异步编程(四)混合模式线程同步

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

FCL中的混合构造

Fcl是framework class library的简称。

ManualResetEventSlim类和SemaphoreSlim类

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

 

Monitor类和同步块

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

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

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

 C#异步编程(四)混合模式线程同步

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

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

C#异步编程(四)混合模式线程同步

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线程才会被解除阻塞。

下面展示了这个类

 C#异步编程(四)混合模式线程同步

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

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模式描述的那样执行丰富的操作。