SpinWait类和Monitor类的一些补充介绍

上一篇文章提到了不加锁实现线程之间的同步,今天参考了其他的资料,所以做一点补充,以便今后参考。

(一)关于SpinWait的介绍(摘自这里

(1)关于如何在多线程环境下保证程序的性能。

不要让线程从用户模式转到内核模式。在Windows上,这是个非常昂贵的操作。比如大家熟知的Critical Section(在.NET上我们叫它Monitor)在等待持有锁时,便在用户模式先旋转等待一段时间,实在不行才转入内核模式。

尽可能用尽量少的线程来完成任务。当超过四个(CPU的数量)线程的时候,操作系统就会以每隔几毫秒~几十毫秒的频率调度线程到CPU。在Windows上,线程上下文切换需要几千个时钟周期。如果进行切换的线程属于另一个进程,开销还会更大,因为操作系统还要切换虚拟地址空间。如果可运行的线程数量等于或小于CPU数量的话,操作系统只运行这些线程,而不会发生上下文切换。在这种情况下,当然性能最佳。

(2)一般的锁(比如Mutex)当线程无法持有时,便会进入内核等待,而Critical Section和Monitor(相当于C#中的lock语句与VB中的SyncLock语句)会先旋转等待(在多处理器的机器上),如果等待超时就会使用信号量进入内核等待。

(3)SpinWait在用户模式下旋转等待(单处理器的时候使用无意义,反而更浪费CPU)。我们为什么要使用SpinWait呢?因为它运行在用户模式下。某些情况下,我们想要在退回到真正等待状态前先旋转一段时间。看起来这似乎很难理解。这根本在做无用功嘛。大多数人在一开始就避免旋转等待。我们知道线程上下文切换需要花费几千个周期(在Windows上确实如此)。我们暂且称其为C。假如线程所等待的时间小于2C(1C用于等待自身,1C用于唤醒),则旋转等待可以降低等待所造成的系统开销和滞后时间,从而提升算法的整体吞吐量和可伸缩性。

SpinWait仅适合在线程等待时间较短,且在SMP或多核环境下。单处理器系统使用没有意义。

(二)关于通常的加锁方式(Monitor类)(参考自这里

(1)使用.NET中提供的各种同步机制的开销对比

用途 是否支持多处理器 开销*
lock (Monitor.Enter / Monitor.Exit) 保证同一时间只有一个线程访问临界资源。 不支持 20ns
Mutex 支持 1000ns
SemaphoreSlim (introduced in Framework 4.0) 保证同一时间不超过一定数量的线程可以访问临界资源。 不支持 200ns
Semaphore 支持 1000ns
ReaderWriterLockSlim (introduced in Framework 3.5) 在同一时刻下,保证只有一个写入线程,但可以有多个读取线程。 不支持 40ns
ReaderWriterLock (effectively deprecated) 不支持 100ns

*Time taken to lock and unlock the construct once on the
same thread (assuming no blocking), as measured on an Intel Core i7 860.

所以,在绝大多数情况下,推荐使用Monitor类进行多线程的同步(第一部分说了Monitor类的执行规则)。

警告:使用锁进行原子操作时,如果发生异常有可能丢失数据:

decimal _savingsBalance, _checkBalance;

void Transfer (decimal amount)
{
  lock (_locker)
  {
    _savingsBalance += amount;
    _checkBalance -= amount + GetBankFee();
  }
}

如果GetBankFee发生异常,那么银行有部分钱就不见了,需要采取其他的措施(比如回滚操作或者使用事物)来避免。

(2)如果加锁的时间太长,就会削弱多线程带来的好处(因为大部分时间只有一个线程可以执行),同时会增加死锁的可能性。

发生死锁时,SQL Server会强制终止并回滚其中的一个事物并抛出异常;而.NET不会,死锁发生时这些线程将永远处于阻塞状态(除非在加锁时指定了超时时间)。

(3)可以考虑使用不可变的对象(immutable)来避免死锁(比如string对象)。

(4)尽量不要简单依靠volatile修饰符来达到线程同步的目的。

 

总之多线程同步是一个技术活,非常考验搬砖工的身手。就我看到的很多程序,多线程的好处并没有体现出来(比如锁定很长时间或干脆直接把一个很大的对象锁掉,或者在不必要的地方也使用大量的锁,在执行数据操作时使用巨长的TransactionScope)。

人的思维模式还是更接近单线程模式,所以看似我们用了很多多线程的技术,在程序执行起来其实基本都是顺序执行的,并没有充分利用多线程的好处。

关于这一点,我们也只能通过学习他人的思想以及在实践中慢慢长进了。

SpinWait类和Monitor类的一些补充介绍”的一个响应

  1. 警告:使用锁进行原子操作时,如果发生异常有可能丢失数据:
    01 decimal _savingsBalance, _checkBalance;
    02
    03 void Transfer (decimal amount)
    04 {
    05 lock (_locker)
    06 {
    07 _savingsBalance += amount;
    08 _checkBalance -= amount + GetBankFee();
    09 }
    10 }

    如果GetBankFee发生异常,那么银行有部分钱就不见了,需要采取其他的措施(比如回滚操作或者使用事物)来避免。

    这段实际上是异常安全性的问题,不管有没有原子操作或者锁操作,要是函数满足强异常安全的话,就应该保证抛出异常的时候可以进行适当的回滚,就好像函数调用没有发生过一样。

    1. 恩,我的意思就是说这不是原子操作。
      不是只要满足了线程安全就能满足业务安全。

发表评论

Fill in your details below or click an icon to log in:

WordPress.com 徽标

You are commenting using your WordPress.com account. Log Out /  更改 )

Google+ photo

You are commenting using your Google+ account. Log Out /  更改 )

Twitter picture

You are commenting using your Twitter account. Log Out /  更改 )

Facebook photo

You are commenting using your Facebook account. Log Out /  更改 )

Connecting to %s