封装ReaderWriterLockSlim
我这里假设了一个队列系统,把最容易出现问题的修改集合和枚举集合2个操作公开出来,方便在多线程中测试效果
以下为测试代码:
static void Main(string[] args) { //建立一个字符串集合,总数为1000 List<string> list = new List<string>(1000); for (int i = 0; i < list.Capacity; i++) { list.Add("字符串:" + i); } MyQueue mq = new MyQueue(list); //保存最后一个值,等下用于做比较 string last = list[list.Count - 1]; //开启1000个线程,同时执行LootFirst方法,并打印出结果 for (int i = 0; i < list.Capacity; i++) { ThreadPool.QueueUserWorkItem(o => { Console.WriteLine(mq.LootFirst()); }); } //在主线程中不停调用mq的遍历方法,这样的操作是很容易出现线程争抢资源的,如果没有锁定访问机制,就会出现异常 while (mq.Count > 0) { foreach (var item in mq) { //如果最后一个值还在,就输出 "还在" if (item == last) { Console.WriteLine("还在"); } } } }
测试结果
Release模式下也是很轻松就跑完了,证明访问的同步控制部分是可以正常工作的
使用详细说明
语法上是不是跟lock比较类似了?Enabled属性的作用在这里就可见一斑了
这部分比较简单,就不多说了.....
对比无lock
当然写完可以用,还需要和原始的方式比较一下,不然不知道优劣
对比无lock模式
将using代码注释,果然出现了异常
对比原始单一lock
对比原始lock模式,这次需要加上时间
UsingLock VS 单一lock
--------
Code平台下载
我写的文章,除了纯代码,其他的都是想表达一种思想,一种解决方案.希望各位看官不要局限于文章中的现成的代码,要多关注整个文章的主题思路,谢谢!
我发布的代码,没有任何版权,遵守WTFPL协议(如有引用,请遵守被引用代码的协议)
我发布的代码,没有任何版权,遵守WTFPL协议(如有引用,请遵守被引用代码的协议)