乐趣区

关于c#:线程安全Ⅱ

作者：

jiezi

在

混合模式

因为用户模式和内核模式各有优劣，为了利用两者各自的有点，因而能够同时应用两种模式来进行结构，在没有线程竞争的时候能够具备用户模式的性能劣势，而在多个线程同时竞争一个结构的时候又能提供不产生自旋的长处，使应用程序的性能失去晋升。

示例代码
class HybridLock : IDisposable
{
    private int m_Waiters = 0;

    private AutoResetEvent m_WaiterLock = new AutoResetEvent(false);

    public void Enter()
    {
        //线程想要取得锁
        if (Interlocked.Increment(ref this.m_Waiters) == 1)
            return; //锁能够应用直,接返回

        //另一个线程正在期待，阻塞该线程
        this.m_WaiterLock.WaitOne(); //产生较大的性能影响
        //WaitOne返回后，这个线程便领有了锁
    }

    public void Leave()
    {
        //这个线程筹备开释锁
        if (Interlocked.Decrement(ref this.m_Waiters) == 0)
            return; //没有其它线程阻塞，间接返回

        //有其它线程正在阻塞，唤醒其中一个
        this.m_WaiterLock.Set(); //产生较大的性能影响
    }

    public void Dispose()
    {
        this.m_WaiterLock.Dispose();
    }
}
剖析代码

HybridLock对象的Enter办法调用了Interlocked.Increment，让m_Waiters字段递增1，这个线程发现没有线程领有这个锁，因而该线程取得锁并间接返回(取得锁的速度十分快)。如果另一个线程染指并调用Enter，此时m_Waiters字段再次递增值为2，发现锁被另一个线程领有，所以这个线程会调用AutoResetEvent对象的WaitOne来阻塞自身(这里因为是内核模式所以会产生性能影响)，避免自旋。

再看看Leave办法，一个线程调用Leave时，会调用Interlocked.Decrement使m_Waiters字段递加1，如果m_Waiters字段是0，阐明没有其它线程在Enter的调用中产生阻塞，这时线程能够间接返回。然而如果线程发现m_Waiters字段的值递加后不为0，阐明存在线程竞争，至多有一个线程在内核中阻塞，这个线程必须只能唤醒一个阻塞的线程，通过调用AutoResetEvent对象的Set办法实现，

自旋、线程所有权和递归

因为转换成内核代码会造成性能损失，而线程占有一个锁的工夫通常比拟短，所以能够先让线程处于用户模式且自旋一段时间，若还未取得锁的权限便可让它转为内核模式，如果线程在期待期间锁变得可用便可防止转为内核模式了。

示例代码(提供自旋、线程所有权和递归反对)
class HybridLock : IDisposable
{
    //用户模式
    private int m_Waiters = 0;

    //内核模式
    private AutoResetEvent m_WaiterLock = new AutoResetEvent(false);

    //管制自旋
    private int m_SpinCount = 1000;

    //用有锁的线程
    private int m_OwningThreadId = 0;

    //领有次数
    private int m_Recursion = 0;

    public void Enter()
    {
        //如果线程曾经领有，递增递归次数并返回
        var threadId = Thread.CurrentThread.ManagedThreadId;
        if(this.m_OwningThreadId == threadId)
        {
            this.m_Recursion++;
            return;
        }

        //尝试获取
        var spinWait = new SpinWait();
        for (int i = 0; i < this.m_SpinCount; i++)
        {
            //如果锁能够应用了
            if (Interlocked.CompareExchange(ref this.m_Waiters, 1, 0) == 0)
                goto GotLock;

            //给其它线程运行的机会，心愿锁会被开释
            spinWait.SpinOnce();
        }

        //自旋完结，依然没有取得锁则再试一次
        if(Interlocked.Increment(ref this.m_Waiters) > 1)
        {
            //有其它线程被阻塞，这个线程也必须阻塞
            this.m_WaiterLock.WaitOne(); //性能损失
            //期待该线程用有锁醒来
        }

    GotLock:
        //一个线程用有锁时，记录ID并指出线程领有锁一次
        this.m_OwningThreadId = threadId;
        this.m_Recursion = 1;
    }

    public void Leave()
    {
        //如果线程不必有锁，bug
        var threadId = Thread.CurrentThread.ManagedThreadId;
        if (threadId != this.m_OwningThreadId)
            throw new SynchronizationLockException("线程未领有锁!");

        //递加递归计数，如果线程依然用有锁，间接返回
        if (--this.m_Recursion > 0)
            return;

        //当初没有线程领有锁
        this.m_OwningThreadId = 0;

        //若没有其它线程被阻塞间接返回
        if (Interlocked.Decrement(ref this.m_Waiters) == 0)
            return;

        //唤醒一个被阻塞的线程
        this.m_WaiterLock.Set(); //性能损失
    }

    public void Dispose()
    {
        this.m_WaiterLock.Dispose();
    }
}
Monitor类

这个类提供了一个互斥锁，这个锁反对自旋、线程所有权和递归，是线程同步罕用的类。

工作形式

CLR初始化时调配一个同步块数组，一个对象在堆中创立的时候，都有两个额定的字段与它关联，第一个字段是“类型对象指针”，它蕴含类型对象的内存地址。第二个字段是“同步索引块”，它蕴含同步块数组中的一个整数索引。

一个对象在结构时，对象的同步块索引初始化为-1，表明不援用任何同步块。而后调用Monitor.Enter时，CLR在数组中找到一个空白同步块，并设置对象的同步块索引来援用该同步块。调用Exit时，会查看是否有其它任何线程正在期待应用对象的同步块，如果没有线程在期待，同步块就能自在被应用了，Exit将对象的同步块索引改回-1，自在的同步块未来能够和另一个对象关联。

堆中对象的同步块索引和CLR的同步块数组元素之间的关系图

Monitor的应用
class SomeType
{
    //对象公有锁
    private readonly object m_Lock = new object();

    public void DoSomething()
    {
        //进入公有锁
        Monitor.Enter(this.m_Lock);
        //其它代码...

        //退出公有锁
        Monitor.Exit(this.m_Lock);
    }
}
ReaderWriterLockSlim类
性能介绍
  • 一个线程写入数据时，申请拜访的其它所有线程都被阻塞
  • 一个线程读取数据时，申请读取的其它线程容许继续执行，但申请写入的线程还是会被阻塞
  • 写入数据的线程完结后，能够解除一个写入线程的阻塞，使它能写入数据，也能够解除所有读取线程的阻塞，让它们并发读取数据。如果没有线程被阻塞，锁就会进入自在状态，容许下一个reader或writer线程获取
  • 读取数据的所有线程完结后，一个writer线程会被解除阻塞，使它能写入数据，如果没有线程被阻塞，锁就会进入自在状态，容许下一个reader或writer线程获取
ReaderWriterLockSlim用法
class SomeType : IDisposable
{
    private readonly ReaderWriterLockSlim m_Lock = new ReaderWriterLockSlim(LockRecursionPolicy.NoRecursion);

    public void DoWrite()
    {
        this.m_Lock.EnterWriteLock();
        //其它代码...

        //退出公有锁
        this.m_Lock.ExitWriteLock();
    }

    public void DoRead()
    {
        this.m_Lock.EnterReadLock();
        //其它代码...

        this.m_Lock.ExitReadLock();
    }

    public void Dispose()
    {
        this.m_Lock.Dispose();
    }
}

在结构ReaderWriterLockSlim对象的时候容许传递一个LockRecursionPolicy标记，如果传递LockRecursionPolicy.SupportsRecursion，锁就能够反对线程所有权和递归行为(这些行为会对锁的性能产生负面影响)，如果反对这些行为锁必须跟踪容许进入锁的所有reader线程，同时为每个线程都独自保护一个递归技术，破费更大的代价，因而倡议结构的时候传入LockRecursionPolicy.NoRecursion。

双检锁(提早初始化)
class Singleton
{
    private static object s_Lock = new object();

    private static Singleton s_Value = null;

    //公有结构
    private Singleton() { }

    public static Singleton GetSingleton()
    {
        if (s_Value != null)
            return s_Value;

        //让一个线程创立它
        Monitor.Enter(s_Lock);
        if (s_Value == null)
        {
            var temp = new Singleton();
            Interlocked.Exchange(ref s_Value, temp);
        }
        Monitor.Exit(s_Lock);
        return s_Value;
    }
}
为何应用Interlocked.Exchange

为何不间接s_Value=new Singleton()，起因在于这种写法编译器可能先为Singleton分配内存，再将援用赋值给s_Value，最初调用结构器。从单线程来看这样并没什么问题，如果是多线程，此时在援用曾经赋值给s_Value了，然而却还未调用结构器，这时另一个线程调用了GetSingleton办法，发现s_Value不为null，所以开始应用Singleton对象，然而对象的结构器还未执行完结，产生bug。而应用Interlocked.Exchange能够修改该问题，办法保障temp中的援用只有在结构器执行完结后才赋值给s_Value。

Monitor类的Wait与Pulse

如果一个线程心愿一个复合条件为true时执行一些代码，便能够应用Wait与Pulse，在条件不满足的时候Wait，另一个线程更改条件后Pulse，而非让线程自旋间断检测条件，节约CPU工夫。

示例代码
class ConditionVariablePattern
{
    private readonly object m_Lock = new object();
    private bool m_Condition = false;

    public void Thread1()
    {
        //获取一个互斥锁
        Monitor.Enter(this.m_Lock);

        //在锁中原子性地检测复合条件
        while (!this.m_Condition)
        {
            //条件不满足，期待其它线程批改
            Monitor.Wait(this.m_Lock);
        }

        //条件满足，解决数据...
        Monitor.Exit(this.m_Lock);
    }

    public void Thread2()
    {
        //获取一个互斥锁
        Monitor.Enter(this.m_Lock);

        //解决数据并批改条件
        this.m_Condition = true;

        //Monitor.Pulse(this.m_Lock);     //开释之后唤醒一个正在期待的线程
        Monitor.PulseAll(this.m_Lock);  //开释之后唤醒所有正在期待的线程

        Monitor.Exit(this.m_Lock);
    }
}
代码解析

Thread1获取一个互斥锁，而后对一个条件变量进行检测，如果条件不满足，调用Monitor.Wait开释锁并阻塞调用线程，其它线程能取得改锁。

Thread2获取锁的所有权，解决数据，造成一些状态的扭转，其中包含Thread1要检测的条件变量，而后调用Monitor.PulseAll或者Monitor.Pulse，从而解除一个因为调用Wait办法而进入阻塞的线程。

其中Pulse只解除期待最久的线程的阻塞，PulseAll解除所有期待线程的阻塞，然而解除阻塞的线程还必须期待Thread2线程调用完Exit能力领有锁。

Thread1醒来时，进行下一次循环迭代，再次对条件进行检测，如过条件仍为false，持续调用Wait。如果条件满足，解决一些数据，最初调用Exit永恒开释锁。

BlockingCollection类实现生产者/消费者模式
static void Main()
{
    //BlockingCollection类实现生产者/消费者模式
    var bl = new BlockingCollection<int>(new ConcurrentQueue<int>());

    //由一个线程池执行生产
    ThreadPool.QueueUserWorkItem(ConsumeItems, bl);

    //在汇合中增加数据项
    for (int i = 0; i < 6; i++)
    {
        Console.WriteLine("production item : {0}", i);
        bl.Add(i);
    }

    //告诉生产线程不会在汇合中增加更多的item了
    bl.CompleteAdding();

    Console.ReadKey();
}
运行后果

生产与消费行为可能呈现交织

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理。

更多文章