在实现生产者/消费者模式时使用 Task.Yield 克服 ThreadPool 饥饿

Question

回答问题：Task.Yield - real usages? 我建议使用 Task.Yield 允许池线程被其他任务重用。在这样的模式下：

  CancellationTokenSource cts;
  void Start()
  {
        cts = new CancellationTokenSource();

        // run async operation
        var task = Task.Run(() => SomeWork(cts.Token), cts.Token);
        // wait for completion
        // after the completion handle the result/ cancellation/ errors
    }

    async Task<int> SomeWork(CancellationToken cancellationToken)
    {
        int result = 0;

        bool loopAgain = true;
        while (loopAgain)
        {
            // do something ... means a substantial work or a micro batch here - not processing a single byte

            loopAgain = /* check for loop end && */  cancellationToken.IsCancellationRequested;
            if (loopAgain) {
                // reschedule  the task to the threadpool and free this thread for other waiting tasks
                await Task.Yield();
            }
        }
        cancellationToken.ThrowIfCancellationRequested();
        return result;
    }

    void Cancel()
    {
        // request cancelation
        cts.Cancel();
    }

但一位用户写道

我不认为使用 Task.Yield 来克服 ThreadPool 饥饿，而 实施生产者/消费者模式是个好主意。我建议你 如果您想详细说明原因，请提出一个单独的问题。

任何人都知道，为什么不是一个好主意？

Answer 1

对于您的问题，cmets 中还有一些优点。作为您引用的用户，我只想总结一下：为工作使用正确的工具。

使用ThreadPool 感觉不是执行多个连续 CPU 密集型任务的正确工具，即使您尝试通过将它们转换为状态机来组织一些协作执行，从而使用await Task.Yield() 相互产生 CPU 时间.线程切换相当昂贵；通过在紧密循环上执行await Task.Yield()，您会增加大量开销。此外，您永远不应该接管整个 ThreadPool，因为 .NET 框架（和底层操作系统进程）可能需要它来处理其他事情。在相关的说明中，TPL 甚至具有 TaskCreationOptions.LongRunning 选项，该选项请求不在 ThreadPool 线程上运行任务（相反，它在幕后创建带有 new Thread() 的普通线程）。

也就是说，使用 custom TaskScheduler 并在一些专用的池外线程上使用有限的并行度，这些线程对单个长时间运行的任务具有线程亲和力可能是不同的东西。至少，await 延续将发布在同一个线程上，这应该有助于减少切换开销。这让我想起了我不久前尝试用ThreadAffinityTaskScheduler 解决的另一个问题。

不过，根据特定情况，使用现有的成熟且经过测试的工具通常会更好。仅举几例：Parallel Class、TPL Dataflow、System.Threading.Channels、Reactive Extensions。

还有一整套现有的工业级解决方案来处理发布-订阅模式（RabbitMQ、PubNub、Redis、Azure 服务总线、Firebase 云消息传递 (FCM)、亚马逊简单队列服务 (SQS) 等）。

Answer 2

在与其他用户就这个问题进行了一番辩论后——他们担心上下文切换及其对性能的影响。 我明白他们在担心什么。

但我的意思是：在循环内做一些事情...... 是一项实质性任务 - 通常以消息处理程序的形式从队列中读取消息并处理它。消息处理程序通常是用户定义的，消息总线使用某种调度程序执行它们。用户可以实现一个同步执行的处理程序（没有人知道用户会做什么），并且没有 Task.Yield 会阻塞线程以循环处理这些同步任务。

不要说空话，我在 github 上添加了测试：https://github.com/BBGONE/TestThreadAffinity 他们将 ThreadAffinityTaskScheduler、.NET ThreadScheduler 与 BlockingCollection 以及 .NET ThreadScheduler 与 Threading.Channels 进行比较。

测试表明，对于超短作业，性能下降是 约 15%。要使用 Task.Yield 而不会降低性能（即使很小） - 不要使用极短的任务，如果任务太短，则将较短的任务组合成更大的批次。

[上下文切换的价格] = [上下文切换时长] / ([作业时长]+[上下文切换时长])。

在这种情况下，切换任务对性能的影响可以忽略不计。但它增加了系统更好的任务协作和响应能力。

对于长时间运行的任务，最好使用自定义调度程序，它在自己的专用线程池上执行任务 - （如 WorkStealingTaskScheduler）。

对于混合作业 - 可以包含不同的部分 - 短期运行的 CPU 限制、异步和长时间运行的代码部分。最好将任务拆分为子任务。

private async Task HandleLongRunMessage(TestMessage message, CancellationToken token = default(CancellationToken))
{ 
            // SHORT SYNCHRONOUS TASK - execute as is on the default thread (from thread pool)
            CPU_TASK(message, 50);
            // IO BOUND ASYNCH TASK - used as is
            await Task.Delay(50);
            // BUT WRAP the LONG SYNCHRONOUS TASK inside the Task 
            // which is scheduled on the custom thread pool 
            // (to save threadpool threads)
            await Task.Factory.StartNew(() => {
                CPU_TASK(message, 100000);
            }, token, TaskCreationOptions.DenyChildAttach, _workStealingTaskScheduler);
}