练习:自己动手实现一个轻量级的信号量(一)
信号量历史悠久,折磨死了一代又一代的计算机专业学生,但是不得不承认其在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优化,并最终实现一个完整的信号量。