上一篇中 我们的女仆终于可以做一些像阳光下其他人一样的事情了，少爷们可以和女仆酱一起参加下午茶~ 难得的上流社会啊
这是永远1v1被人私有的女奴 和 喝茶时被人共有的女仆酱最明显的差异~
明媚的午后阳光下，庭院里白色长餐桌两旁，英俊的少爷们彼此交换着最近的趣闻轶事，一面欣赏女仆酱以1/3几率打翻茶水，可爱而笨笨地努力侍奉着，闪闪发光的样子。
人间极乐喵~~~~~~~~~~ :3
但距离真正的自由~~无Lock还是很远,很远。
因为，
老爷和少爷的调教仍然是一如既往的频繁！ 女仆酱你仍然是伟大的老少爷们的东西~！
我们看上一次所说的调用聊天室方式：
Code Snippet
这个行程可不得了
所有的少爷和老爷都是这个行程 执事先生，您是恶魔执事来的吧！(塞巴斯酱邪媚一笑)
虽然效率高了近一倍,但是 在奉茶的时候 仍然有调教的队伍大排长龙~
这让老少爷们很是不 不不爽 ！ “主人样”们是不会这样满足地口胡！~ 啊 太激动了，咽口水先。
-------------------------------------------------------------------------------------
最年轻的少爷在某个风和日丽的下午茶时间 提出了一个邪恶点子：
“既然我们喝茶的时候只是想看着女仆酱，又不是真的希望她倒茶，为啥我们不能一边看着别人调教女仆酱 一边喝茶呢？”
全体老少爷们的红茶都化作血雾喷洒在无瑕的桌上，纷纷气绝。
小少爷解释道：
既然数据池实际上是一个队列 而加入队列仅仅是对队列头有所操作，
那么在已经访问过的节点另一端加入的内容 对于已经开始访问内部内容的线程来说是毫无意义的
为了“不存在”的变化加锁,这又是何苦呢？
“囊得斯嘎！？”
“艘得斯嘎！！”
“游息！！”
爬起来的各位纷纷恍然大悟装，激动地握住彼此的手，泛着泪光。。。。
可是为什么我们之前要加锁呢？
深入研究Queue<T> 的源代码 我们了解到 Queue<T>的实现方法：定长数组实现的循环队列
不熟悉循环队列的兄弟们可以参考博友刺儿头的文章
当每次 ToArray的时候 Queue<T>执行下面的操作
Code Snippet
同时有人Enqueue的时候 _size _head _tail 都可能被并发修改
Code Snippet
太危险了！
我们是为了保障这些关键标记量才用的Lock 这是数组内核本身限制造成的:(
我们一开始就陷入了 “要用队列，M$提供了队列”的心理陷阱，
——果然观赏女仆酱一定要喝茶是错误的常识
——看来聊天数据池还真的不能拿来主义
对于微软类库做不到的 我们一定要有自己的实现。 所以女仆酱啊，你的末日到了欧欧欧欧喝喝喝喝喝喝HiaHiaHia …..
敬请期待下一篇:
垃圾列表
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。