摘要: 本系列意在记录Windwos线程的相关知识点，包括线程基础、线程调度、线程同步、TLS、线程池等。
这篇来说说静态的Interlocked类和ReadWrite锁
.NET中的Interlocked
Interlocked的系列方法提供了对简单类型的原子操作（不会被打断的操作），因此这也是一种多线程共享变量，防止冲突争用的方法。
比如下面的方法作用是以原子的方式递增整数i：
int i = 0 ;Interlocked.Increment( ref i);
除此之外还包括Add、Exchange、CompareExchange、Decrement、Read和其中的某些泛型版本。如果看官使用过windows API自带的Interlock系列函数，可能已经发现了：这里的Interlocked类应该只是封装了windows API的调用。在中详细阐述了Interlocked系列函数的存在意义和使用方法，作为对比下面列出.NET版本和windows API版本：
| .NET | API | 说明 |
| Interlocked.Add | InterlockedExchangeAdd | 对某个变量做加法 |
| Interlocked.Increment | InterLockedIncrement | 递增变量 |
| Interlocked.Decrement | InterLockedDecrement | 递减变量 |
| Interlocked.Exchange | InterlockedExchange | 对变量赋值 |
| Interlocked.CompareExchange | InterlockedCompareExchange | 对变量比较后赋值（参数1与参数3比较，如果相同，把参数2赋值给参数1） |
此外，Windows API还提供InitializeSListHead/InterlockedPushEntrySList/InterlockedPopEntrySList/InterlockedFlushSList/QueryDepthSList来构建单链表栈，参见：
对于Interlocked.CompareExchange，之前在园子里看到一篇关于单例的文章：。文章大意是由于对象在通过new关键字创建时，可能会先将引用赋值给目标变量，再调用构造器，因此，在单例模式中的“双检测技术”可能会有隐含的bug。最后作者提出替代方案使用了Interlocked.CompareExchange，这里照搬过来了：
internal sealed class MySingleton{ private static MySingleton s_value = null; public static MySingleton GetMySingleton() { if (s_value != null) return s_value; MySingleton temp = new MySingleton(); Interlocked.CompareExchange(ref s_value, temp, null); return s_value; }}
.NET中的ReaderWriterLock
有时对于共享资源应当区分读和写，因为读的时候往往是允许多线程同时读的，因为这不会造成混乱；而只有在需要写的时候才不允许其他线程读或者写。.NET的和为我们提供了区分读和写的锁。这种方式在有些情况下通常比Monitor更高效。在MSDN中推荐使用的是ReaderWriterLockSlim类，其解释是ReaderWriterLockSlim用一种简单的规则处理递归调用以及更好的支持锁升级机制，而且能更好的避免死锁的发生，最后它比ReaderWriterLock更高效。由于两者十分相似，所以这里就对ReaderWriterLockSlim作个简单的讨论。
首先，应当尽量避免在同一个线程中多次对请求一个锁，典型的情况就是递归的调用，因为这往往容易死锁。因此，ReaderWriterLockSlim的默认无参构造函数是不允许递归的，当然你也可以设置允许递归：
public ReaderWriterLockSlim( LockRecursionPolicy recursionPolicy)
对于ReaderWriterLockSlim锁，一个线程试图获取锁的时候分三种模式：
- Read Mode：读模式，表示线程试图对共享资源进行读操作，而不会写。ReaderWriterLockSlim.EnterReadLock\ReaderWriterLockSlim.TryEnterReadLock
- Write Mode：写模式，表示线程试图对共享资源进行写操作。ReaderWriterLockSlim.EnterWriteLock\ReaderWriterLockSlim.TryEnterWriteLock
- Upgradeable Read Mode：读模式，但可能将来升级成写锁。ReaderWriterLockSlim.EnterUpgradeableReadLock\ReaderWriterLockSlim.TryEnterUpgradeableReadLock
在不考虑同一个线程递归请求锁的情况下：
- 同一时刻只能有一个线程获得写锁，在有线程获得写锁的时候，其他线程将无法获得任何类型的锁；
- 同一时刻只能有一个可升级的读锁，在有线程获得可升级读锁的时候，其他线程只能获得读锁；
- 同一时刻读锁可以被多个线程获得，除了上述两种情况；
读锁升级
同一时刻只能有一个线程获得可升级读锁，当获得可升级读锁的线程试图获得写锁的时候或可以调用EnterWriteLock，如果此时有线程没有释放写锁的话，EnterWriteLock会阻塞直到所有的读锁释放，同时试图获得读锁的线程也将阻塞（这里不用考虑写锁，因为既然可以获得可升级读锁，那么必然不存在写锁），这有点像“关门放狗”，关上门不让狗进来，而把已经在里面的狗放走。：）
请参考MSDN上的例子理解ReadWriterLockSlim：
ReaderWriterLockSlim和Slim读/写锁
在中介绍了Windows API提供的读写锁同步方式。下面的表格对两种API做了比较：
| .NET | API | 说明 |
| ReaderWriterLockSlim构造 | InitializeSRWLock | |
| ReaderWriterLockSlim.EnterWriteLock | AcquireSRWLOckExclusive | |
| ReaderWriterLockSlim.TryEnterWriteLock | -- | |
| ReaderWriterLockSlim.ExitWriteLock | ReleaseSRWLockExclusive | |
| ReaderWriterLockSlim.EnterReadLock | AcquireSRWLockShared | |
| ReaderWriterLockSlim.TryEnterReadLock | -- | |
| ReaderWriterLockSlim.ExitReadLock | ReleaseSRWLockShared | |
| ReaderWriterLockSlim.EnterUpgradeableReadLock | -- | |
| ReaderWriterLockSlim.TryEnterUpgradeableReadLock | -- | |
| ReaderWriterLockSlim.ExitUpgradeableReadLock | -- | |
| -- | CONDITION_VARIABLE | API提供了条件变量的支持 |
| 可以递归特性 | -- | .NET提供了递归 |
从上表中可以看到，.NET的版本具有以下特点：
- 提供对应的TryXXX方法
- 提供可升级写锁特性
- 提供可递归的特性
-
不提供条件变量的用法
劳动果实，转载请注明出处：