在C＃中用于大量IO操作的线程类型

问题描述

我的任务是更新操作中非常单线程的c＃应用程序（非gui），并向其中添加多线程以使其更快地完成工作。

每个线程将需要执行非常少量的计算，但是大多数工作将在调用并等待sql Server请求。因此，与cpu时间相比，有很多等待。

几个要求将是：

在某些有限的硬件（即仅几个内核）上运行。当前系统在“推”入时仅占用约25％的cpu。但是，由于它主要是在等待sql Server响应（不同的服务器），因此我们希望具有比核心更多线程的功能。
能够限制线程数。我也不能只拥有无限数量的线程。我不介意通过数组，列表等来限制自己。
能够跟踪这些线程何时完成，以便进行一些后处理。

在我看来，.NET Framework有许多不同的线程处理方式，我不确定在此任务中是否有一种方法优于另一种。我不确定是否应该使用Task，Thread，ThreadPool，还有其他一些东西……async \ await模型在这种情况下不是很好，因为它等待一项特定任务完成。

解决方法

我不确定是否应该使用Task，Thread，ThreadPool等其他东西...

对于您而言，这比您想像的要重要。您可以专注于最适合您（现有）代码样式和数据流的内容。

因为它主要是在等待SQL Server响应

您的主要目标是使尽可能多的SQL查询并行进行。

能够限制线程数。

不必担心太多。在拥有25％CPU的4核上，您可以轻松拥有100个线程。有关64位的更多信息。但是您不希望有数千个线程。 .net线程至少占用1MB的空间，估计可以节省多少RAM。

因此，这取决于您的应用程序，您可以同时运行多少个查询。首先要担心线程安全。

当并行查询的数量> 1000时，您将需要async / await在更少的线程上运行。

只要它Parallel.ForEach()，Parallel.Invoke()等看起来像是很好的工具。

100-1000范围是灰色区域。

为其添加多线程以使其更快地处理工作队列。

每个线程将需要执行非常少量的计算，但是大多数工作将在调用并等待SQL Server请求。因此，与CPU时间相比，有很多等待。

通过这种处理，还不清楚多线程如何使您受益。多线程是并发的一种形式，并且由于您的工作负载主要是受I / O约束的，因此异步（而非多线程）将是首先要考虑的问题。

在我看来，.NET Framework有许多不同的线程处理方式，我不确定在此任务中是否有一种方法比另一种更好。

的确。作为参考，Thread和ThreadPool如今已成为传统。有更好的高级API。如果将Task用作委托任务（例如Task.Factory.StartNew），也应该很少。

在我看来，异步\等待模型在这种情况下并不适合，因为它等待一个特定任务完成。

await将一次等待一个任务，是的。 Task.WhenAll可用于合并多个任务，然后您可以await处理合并的任务。

让它更快地完成工作队列。

能够限制线程数。

能够跟踪这些线程何时完成，以便我可以进行一些后处理。

在我看来，TPL Dataflow是您系统的最佳方法。数据流允许您定义数据流经的“管道”，其中某些步骤是异步的（例如，查询SQL Server），而其他步骤是并行的（例如，数据处理）。

我在问一个高层次的问题，试图找回高层次的答案。

您可能对my book感兴趣。

在我看来，异步\等待模型在这种情况下并不适合，因为它等待一个特定任务完成。

那是错的。异步/等待只是一种语法，用于简化异步代码的状态机机制。它等待而不消耗任何线程。换句话说，async关键字不会创建线程，await不会保留任何线程。

能够限制线程数

请参阅How to limit the amount of concurrent async I/O operations?

能够跟踪这些线程何时完成，以便我可以进行一些后处理。

如果您不使用“一劳永逸”模式，则只需编写await task

就可以跟踪该任务及其异常

var task = MethodAsync();
await task;
PostProcessing();

async Task MethodAsync(){ ... }

或者对于类似的方法，您可以使用ContinueWith：

var task = MethodAsync();
await task.ContinueWith(() => PostProcessing());

async Task MethodAsync(){ ... }

了解更多：

Releasing threads during async tasks

https://docs.microsoft.com/en-us/dotnet/standard/asynchronous-programming-patterns/?redirectedfrom=MSDN

TPL Dataflow库可能是这项工作的最佳选择之一。这是构建一个由两个块组成的简单数据流管道的方法。第一个块接受一个文件路径并产生一些中间数据，这些中间数据随后可以插入数据库中。第二个块通过将它们发送到数据库来消耗来自第一个块的数据。

var inputBlock = new TransformBlock<string,IntermediateData>(filePath =>
{
    return GetIntermediateDataFromFilePath(filePath);
},new ExecutionDataflowBlockOptions()
{
    MaxDegreeOfParallelism = Environment.ProcessorCount // What the local machine can handle
});

var databaseBlock = new ActionBlock<IntermediateData>(item =>
{
    SaveItemToDatabase(item);
},new ExecutionDataflowBlockOptions()
{
    MaxDegreeOfParallelism = 20 // What the database server can handle
});

inputBlock.LinkTo(databaseBlock);

现在，每次用户上载文件时，您只需将文件保存在临时路径中，然后将该路径发布到第一块即可：

inputBlock.Post(filePath);

就是这样。数据将从流水线的第一个块自动流到最后一个块，并根据每个块的配置进行转换和处理。

这是一个故意简化的示例，用于演示基本功能。生产就绪的实现可能会定义更多的选项，例如CancellationToken和BoundedCapacity，它将监视inputBlock.Post的返回值以防万一该块不能接受作业，可能有completion propagation，请注意databaseBlock. Completion属性中的错误等。

如果您对遵循此方法感兴趣，那么最好对库进行一些研究，以熟悉可用的选项。例如，有一个TransformManyBlock可用，适用于从单个输入产生多个输出。 BatchBlock在某些情况下也可能有用。

TPL数据流内置在.NET Core中，并且可以作为package用于.NET Framework。它有一些学习曲线，需要注意一些陷阱，但这并不可怕。

c#c#multithreading threadpool