在WCF方法中使用Task.WaitAll

Question

我有一个.NET 4.5.1 WCF服务,它处理来自数千个用户将使用的应用程序的同步.我目前使用Task.WaitAll,如下所示,它工作正常,但我读到这很糟糕,可能导致死锁等等.我相信我曾经尝试过WhenAll而且它没有用,我不记得这些问题我再次回到这里进行审查,以确保我做得对.我担心的是在这种使用中是否需要阻塞和首选,WCF服务方法因此WaitAll似乎没有问题地工作.

我有大约十几种方法,每种方法都更新实体框架6中的实体,用现有数据处理传入数据并进行必要的更改.这些方法中的每一种都很昂贵,所以我想主要使用并行性来使所有方法在这个功能强大的24核服务器上同时工作.每个方法返回为Task,在Task.Run中包装其内容.DoSync方法创建了一个新List,并将每个同步方法添加到列表中.然后我调用Task.WaitAll(taskList.ToArray())并且所有工作都很棒.

这是正确的做法吗？我想确保此方法可以很好地扩展,不会导致问题,并在WCF服务方案中正常工作.

Answer 1

在高规模服务中,使用异步IO(通常不是 - 您使用Task.Run)通常是个好主意."高规模"的定义非常松散.异步IO在服务器上的好处是它不会阻塞线程.这导致更少的内存使用和更少的上下文切换.这就是它的全部.

如果您不需要这些好处,可以使用同步IO并阻止您喜欢的所有内容.什么都不会发生.明白,在后台线程上运行10个查询并等待它们将暂时阻塞11个线程.这可能没问题,也可能没问题,具体取决于您期望的并发操作数.

我建议您对async IO的可扩展性优势进行一些研究,以便您更好地了解何时使用它.请记住,异步会花费成本:开发速度较慢,并发错误较多.

要明白,async IO与使用thread-pool(Task.Run)不同.线程池不是无线程的,而async IO根本不使用任何线程.甚至不是运行时管理的"不可见"线程.

我经常发现的是:如果你不得不问,你不需要它.