信号量历史悠久，折磨死了一代又一代的计算机专业学生，但是不得不承认其在Multi-thread环境下的巨大作用。最经典的案例莫过于管理一个环状缓冲区。.NET 中的Semaphore对象等同于Win32中的Semaphore。属于内核级对象，因此使用它的代价就比较大了。并且Semaphore对象每次仅仅能够等待一个Count，这有的时候让事情变得有些烦，例如你可能不得不将环状缓冲区分割为一个个的Chunk（实际上这是一个好方法，因为我们应该对于Cache进行优化）。Qt中的信号量可以一次获得多个Count，感觉很方便。综上，我们希望自己动手实现一个轻量级的，支持一次获得多个资源的信号量。
首先看看信号量重要维护哪些信息。第一，当前还有多少剩余的资源（_currentResources）；第二，系统初始化的时候有多少资源（_initResources）；第三，当前有多少个线程被阻塞（_waitingThreadCount）：
2 {
3 private int _currentResources;
4 private int _initResources;
5 private volatile int _waitingThreadCount;
6 }
我们知道，如果信号量持有的资源数目没完没了的减少，那么降到0就会阻塞，但是没完没了的增加呢？厄~你说会溢出，所以，我们还需要进行一个上限的检查。于是我们添加了一个上限值，这个上限值应该由用户指定，并且一旦指定就不能更改了。于是我们的代码中添加了一个新的Field。
2 {
3 private int _currentResources;
4 private int _initResources;
5 private volatile int _waitingThreadCount;
6 // 资源数目的上限
7 private readonly int _maxResourceCount;
8 }
好的，你发现了，我们的需要管理的Fields不止一个，那么~~对了，为了保证某些操作的一致性，我们肯定需要一把锁。
2 {
3 private int _currentResources;
4 private int _initResources;
5 private volatile int _waitingThreadCount;
6 private readonly int _maxResourceCount;
7 // 信号量对象的锁
8 private object _globalLock;
9 }
好了，下面我们可以开始我们的工作了。下一步我们干什么呢？厄~咱们解决掉关键问题之后剩下的工作肯定轻松愉快，因此，我们先考虑Wait和Release吧。
首先解决Release的问题，想想Release要做哪些事情。
（1）看看当前的资源数目加上释放的数目会不会超过上限
（2）如果不超过上限就增加我们的资源数目
（3）如果发现有的线程在等待资源则激活那些线程，让他们看看现有的资源是不是够他们使用了
（4）将之前的资源数目返回给用户。还有关键的一点，这些操作必须保证是Atomic的，于是这些操作都需要lock!
写代码了~~~
2 {
3 // 参数需要检查一下
4 if (releaseResCount < 1 )
5 throw new ArgumentOutOfRangeException( " releaseCount " );
6 // 这个函数需要保证其结果的一致性
7 lock ( this ._globalLock)
8 {
9 // 已经超过了上限了
10 if ( this ._maxResourceCount - this ._currentResources < releaseResCount)
11 {
12 throw new System.Threading.SemaphoreFullException();
13 }
14 // 很好，现在我们在做第（2）步
15 this ._currentResources += releaseResCount;
16 // 我们现在可以做第（3）步了
17 // 为了性能考虑，我们应当分两种情况进行讨论。
18 // 当然了，如果没有线程等待就不管了~
19 // 什么？万一你在判断的时候等待的线程增加了怎么办？有锁呢，不可能~
20 if ( this ._waitingThreadCount == 1 )
21 {
22 System.Threading.Monitor.Pulse( this ._globalLock);
23 }
24 else if ( this ._waitingThreadCount > 1 )
25 {
26 System.Threading.Monitor.PulseAll( this ._globalLock);
27 }
28 // 这就是第（4）步
29 return ( this ._currentResources - releaseResCount);
30 }
31 }
以上的代码正确么？答案是错误的！错误在了第（3）步，最终导致第4步结果可能是错误的。
问题出在了Pulse上。如果你发现看MSDN上的解释有些头晕，那么我们就用伪代码解释一下。
Monitor.Pulse(...)
等价于
if(_globalLock.Owner == Thread.CurrentThread)
{
Monitor.Exit(_globalLock);
}
else
{
throw new ...;
}
InternalPulse(...);
Monitor.Enter(_globalLock);
问题已经出来了，实际上我们唤醒线程时释放了锁，唤醒之后只有重新获得锁之后才能继续，而这个时候信号量拥有的资源数目很可能已经改变了！我们说，Release返回给用户的数据是调用Release之前信号量所保有的资源数目，那么，我们就应当提前保存这个值。修改一下：
2 {
3 // 参数需要检查一下
4 if (releaseResCount < 1 )
5 throw new ArgumentOutOfRangeException( " releaseCount " );
6 // 这个函数需要保证其结果的一致性
7 lock ( this ._globalLock)
8 {
9 // 已经超过了上限了
10 if ( this ._maxResourceCount - this ._currentResources < releaseResCount)
11 {
12 throw new System.Threading.SemaphoreFullException();
13 }
14 // 很好，现在我们在做第（2）步
15 int old = this ._currentResources;
16 this ._currentResources += releaseResCount;
17 // 我们现在可以做第（3）步了
18 // 为了性能考虑，我们应当分两种情况进行讨论。
19 // 当然了，如果没有线程等待就不管了~
20 // 什么？万一你在判断的时候等待的线程增加了怎么办？有锁呢，不可能~
21 if ( this ._waitingThreadCount == 1 )
22 {
23 System.Threading.Monitor.Pulse( this ._globalLock);
24 }
25 else if ( this ._waitingThreadCount > 1 )
26 {
27 System.Threading.Monitor.PulseAll( this ._globalLock);
28 }
29 // 这就是第（4）步
30 return old;
31 }
32 }
好，目前我们轻松的解决了Release问题。但是Wait就不是那么好办的了。想这个花掉很多脑细胞。首先一个问题，Wait可能阻塞，所以必须支持超时操作。其次就是必须考虑线程唤醒之后的工作。
我们还是先理一下思路。Wait试图减少资源数目。如果失败就需要不停的等待，直到他被别人唤醒。首先用文字书写一下：
（1）试图获得锁！这是必须的因为没有锁的话我们根本没有办法保证操作的一致性。这个时候我们不能够使用lock{...}因为我们必须处理超时的问题。
（2）好样的，锁在我们手里了，现在我们要试图减少资源数目：
while(当前的资源数还不够我们减少的)
{
// 也就是说我们必须等待了
if (已经超时了)
{
返回;
}
释放掉锁并让线程处于等待状态。如果超时就返回；
// 好了，执行到这一句说明我们已经持有锁了，有人把我们唤醒了
// 但是唤醒了不代表我们就有我们需要的资源了所以循环回去检查
}
// 能执行到这一句说明：（a）我们拥有锁，（b）我们有足够的资源
减少资源数目；
（3）释放锁。
我们来写代码！
2 {
3 // 参数检查工作是必须的
4 if (millisecondsTimeout < - 1 )
5 throw new ArgumentOutOfRangeException( " millisecondsTimeout " );
6 if (waitResNumber < 1 )
7 throw new ArgumentOutOfRangeException( " waitResNumber " );
8 // 我们在后面要两次处理超时，因此我们需要一个计时器
9 System.Diagnostics.StopWatch watch = null ;
10 if (millisecondsTimeout != - 1 )
11 {
12 watch = System.Diagnostics.Stopwatch.StartNew();
13 }
14 // 现在我们来做第（1）步
15 if ( ! System.Threading.Monitor.TryEnter( this ._globalLock))
16 {
17 if (millisecondsTimeout == 0 )
18 return false ;
19 if ( ! System.Threading.Monitor.TryEnter( this ._globalLock, millisecondsTimeout))
20 {
21 return false ;
22 }
23 }
24 // 现在我们已经获得锁了，我们要增加阻塞的线程数目，以便将来有人能够唤醒我们
25 ++ this ._waitingThreadCount;
26 try
27 {
28 // 如果当前的资源数目不够用的，我们就得等等了
29 while ( this ._currentResources - waitResNumber < 0 )
30 {
31 if (millisecondsTimeout != - 1 )
32 {
33 // 看看是不是超时了
34 timeoutNum = UpdateTimeout(watch, millisecondsTimeout);
35 if (timeoutNum <= 0 )
36 {
37 return false ;
38 }
39 }
40 // 如果没有超时我们就再等一下
41 if ( ! System.Threading.Monitor.Wait( this ._globalLock, timeoutNum))
42 {
43 return false ;
44 }
45 // 好的我们被唤醒了，赶快回去检查检查有没有足够的资源了
46 }
47 // 很好，我们现在有足够的资源了，
48 // 并且没有什么人能够再更改资源数目了，因为锁在我们手里！
49 this ._currentResources -= waitResNumber;
50 }
51 finally
52 {
53 // 很好，我们安全的退出了，减少阻塞的线程数目并且释放锁
54 -- this ._waitingThreadCount;
55 System.Threading.Monitor.Exit( this ._globalLock);
56 }
57 return true ;
58 }
好的！我们基本上实现了一个信号量的精华部分了。但是这是不够的。尤其是在Wait的过程中，我们直接就使用了Monitor，实际上，对于多核心处理器来说，一开始进行短暂的spin是更好的选择！我们的代码还有优化的空间！下一回，我们就在Wait中添加Spin优化，并最终实现一个完整的信号量。
扫一扫
759
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
