之前讨论了基元用户模式和内核模式线程同步构造。其他所有线程同步构造都基于它们,而且一般都合并了用户模式和内核模式构造,我们称为混合线程同步构造。没有线程竞争时,混合构造提供了基元用户模式构造所具有的性能优势。多个线程竞争一个构造时,混合构造通过基元内核模式的构造来提供不自旋的优势。由于大多数应用程序的线程都很少同时竞争一个构造,所以性能上的增强可以使你的应用程序表现得更出色。
本章最后展示如何使用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的性能,我情愿有一个性能高超的锁,并确保我的代码以正确的方式使用它。你会注意到,事件和信号量都没有维护这种信息,只有互斥体才有维护。
自旋、线程所有权和递归
由于转换为内核模式会造成巨大的性能损失,而且线程占有锁的时间通常很短,所以为了提升应用的总体性能,可以让一个线程在用户模式自旋一小段时间,再让线程转换为内核模式。如果线程正在等待的锁在自旋期间变得可用,就能避免模式转换了。
此外,有的锁限制只能由获得锁的线程释放锁,有的锁允许递归,所以可以通过一些逻辑支持自旋、线程所有权和递归,下面是一个例子:
![](https://i-blog.csdnimg.cn/blog_migrate/8f900a89c6347c561fdf2122f13be562.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/961ddebeb323a10fe0623af514929fc1.gif)
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(); } }
执行结果
注意,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模式描述的那样执行丰富的操作。