您的位置:知识库 » .NET技术

.Net 4.0并行库实用性演练

作者: XiaoMing  发布时间: 2010-09-14 12:59  阅读: 3175 次  推荐: 0   原文链接   [收藏]  
摘要:文中作者深入浅出的介绍了.Net4.0的并行编程,利用.Net 4.0的并行库实际编写了几段代码,供大家学习参考。
[1] .Net 4.0并行库实用性演练
[2] .Net 4.0并行库实用性演练
[3] .Net 4.0并行库实用性演练

 

  接着上一次说,即使用了新的线程安全的集合BlockingCollection,这段代码还是会有问题。

static void testFillParallel()
{
    var list = new BlockingCollection<Person>(9999);
    Enumerable.Range(1, 99999).AsParallel().ForAll(n =>
    {
        var name = "Person " + n % 9;
        if (list.Count(p => p.Name == name) < 1) list.Add(new Person { Id = n, Name = name });
    });
    Console.WriteLine("Person's count is {0}", list.Count);
}

代码逻辑就是根据序号生成一个名字,并将名字不重复的人加入集合中。显然,最后集合中应该有9个人,应该很简单吧。执行一下,请看结果:

  可见,绝大多数结果都是正确,只有两次执行出现了异常,在正式系统运行中,这可是要命的两条!难道是BlockingCollection的问题吗?细想不太可能,微软怎么也不会漏过这么明显的设计问题,实际上是自己对线程安全认识不准确。集合元素之所以偶尔会多一个,是这样的情况:线程A抢先一步,占住集合判断是否存在这个人名,线程B被BlockingCollection拦在外面;A发现集合中查无此人,正想加一个,然而不知怎么回事,它没马上继续,就好像龟兔赛跑,兔子要到终点了,做了个白日梦,梦一醒自己成了老二。B趁机赶上,正好锁也解了,碰巧它查的人也没有,一鼓作气跑完全程。这时A跑了一大半,岂肯甘心,赖皮着到终点,不管三七二十一,有没有和B刚才加的重复,硬把自己塞了进去。

  这样理解,也容易解释,第一次执行出现异常结果概率很高,因为开始时线程间步调几乎完全一致,刚才故事的前半段最有可能上演。另外条件判断时间越久,异常结果出现概率越小,比如把name = "Person "+ n % 9改成name = "Person "+ n % 50,这时A就是做白日梦,B也全力追赶,无奈前面被落后太多,一千次中只有一两次结果异常。

  其实System.Collections.ConCurrent命名空间底下的类,只对多线程环境下的某次访问保证健壮性,却不能保证多线程下,作为业务对象的业务操作的准确性,实际上也无法做到。然而话说回来,我们使用这些类,是让它们在凶险的多线程战场上,为我们奋勇杀敌,而不是明哲保身的。如果业务出错了,仗都打输了,集合再线程安全亦无济于事。所以,不要让线程安全误导我们,要着眼在业务上,业务安全实现了,自然线程安全自然不在话下。

  现在要解决结果异常,自然又想到了老办法—上锁,先保证万无一失。显然,并行集合也不必上场了,还是用List。为了接近真实场景,将集合最大元素数目提高到999,这样在判断新元素是否重复是要花较多时间,取代Thread.Sleep(1),代码如下:

static void testFillParallel()
{
    var list = new List<Person>(999);
    var L = new object();
    Enumerable.Range(1, 9999).AsParallel().ForAll(n =>
    {
        var name = "Person " + n % 999;
        lock (L)
        {
            if (list.Count(p => p.Name == name) < 1) list.Add(new Person { Id = n, Name = name });
        }
    });
    Console.WriteLine("Person's count is {0}", list.Count);
}

测试结果如下:

 次数

 1

 2

 3

 4

 Fill 方法

 304

 292

 291

 292

 FillParallel 方法

 340

 298

 296

 297

  可见,虽然运用并行方式,也保证每个迭代有一定的执行时间,虽然加锁可以保证结果正确,但大多数时候,只有一个线程能进行工作,其他线程再多也只能等待,实际上还不如单线程,也失去了并行运算的意义。

  学习.Net4.0 的并行库并非我们的目的,我们目的是解决现实的问题。解决关键,还是在锁上。锁是把双刃剑,我们要让线程占用锁时间尽可能短。在填加集合时,加锁没办法避免,但只是为遍历集合而加锁,好像是种浪费。根据三级锁协议,应该允许多个只读操作同时进行,可是实现IEnumerable的集合,都不允许在遍历访问时修改集合,既然如此,我们自己搞一个集合副本,只作判断用,如果原集合更新,副本也随之更新,不是就能解决同时遍历的问题了吗?

  试验代码:

static void testFill()
{
    var list = new List<Person>(999);
    var L = new object();
    Enumerable.Range(1, 9999).ToList().ForEach(n =>
    {
        var name = "Person " + n % 999;
        if (list.Count(p => p.Name == name) < 1) list.Add(new Person { Id = n, Name = name });
    });
    Console.WriteLine("Person's count is {0}", list.Count);
}

static void testFillParallel()
{
    var list = new List<Person>(999);
    var L = new object();
    var resultCopy = new Person[999];
    bool hasNewMember = false;
    Enumerable.Range(1, 9999).AsParallel().ForAll(n =>
    {
        var name = "Person " + n % 999;
        if (resultCopy.Count(p => p!=null && p.Name == name) < 1)
        {
            lock (L)
            {
                // 如果有新成员,要再判断一遍
                if (hasNewMember)
                {
                    if (resultCopy.Count(p => p != null && p.Name == name) > 0) return;
                    hasNewMember = false;
                }
                list.Add(new Person { Id = n, Name = name });
                list.CopyTo(resultCopy);
                hasNewMember = true;
            }
        }
    });
    Console.WriteLine("Person's count is {0}", list.Count);
}

试验结果(单位ms):

 次数

 1

 2

 3

 4

 Fill 方法(和上次一样)

 309

 291

 292

 292

 FillParallel 方法

 210

 166

 165

 166

  看来,自己总算写了第一段能发挥并行运算的代码。

  当然,最后代码还有很多可改进的地方,比如list.CopyTo方法,还有发现有新成员后第二次判断,向让性能与CPU核数正比的目标努力。

  还有,那个if(...){ lock(...){ if(...){的语句,跟单例模式的一种普遍实现很像,单例模式也是多线程环境下一种设计模式,也许其中有些异曲同工之处吧。

0
0
 
标签:.Net 并行库

.NET技术热门文章

    .NET技术最新文章

      最新新闻

        热门新闻