光纤与异步等待答案

【问题标题】：Fibers vs async await光纤与异步等待
【发布时间】：2015-09-22 03:29:39
【问题描述】：

我正在加入一个 C# 项目，其中开发人员大量使用 Fibers。在这个项目之前，我什至没有听说过它们，并且以前在我的多任务操作中使用过 async await 和 Threads 和 BackgroundWorkers。今天我问他们为什么使用Fibers，主要开发人员说他更容易调试。这意味着他知道特定函数来自哪个线程，甚至可以访问堆栈中更高的变量。

我想知道使用Fibers 与使用新的async await 和使用Threads 的优缺点是什么。

PS：我们使用的是 .Net 4.5

【问题讨论】：

你指的使用什么Fiber实现？ Windows Fiber API?
确实，当您暂停调试器时，您看不到应用程序在做什么，因为所有线程大部分时间都没有做任何事情。这是异步 IO 的一大缺点。不过，我绝不会推荐纤维。
光纤比任务更昂贵。光纤需要 1MB 的内存用于堆栈。任务需要内存用于局部变量，但它们使用调度程序的堆栈。
@timmyl 抱歉回复晚了。它是使用 Enumarables 手动实现的
在那种情况下，由于它不是操作系统级别的光纤，我能想到的一种情况是严格的内存占用限制，因此您希望您的应用程序在一个线程 + 普通 CLR 基础架构线程上运行。与枚举器合作的多任务处理是实现这一目标的一种方法。那说它的工作量很大。我认为你需要一个强有力的理由来走这条路，因为 CLR 线程池和异步 I/O 非常强大。提供有关您正在处理的系统类型及其具有的任何特殊限制的更多背景信息可能会有所帮助。

标签： c# multithreading asynchronous async-await fibers

【解决方案1】：

我问他们为什么使用 Fibers，主要开发人员说他更容易调试。这意味着他知道哪个线程特定函数来自甚至可以访问变量在堆栈中更高。

这听起来很奇怪。将任务并行库与默认 ThreadPoolTaskScheduler 以外的自定义调度程序一起使用时，您可以自己决定如何安排任务（不一定在新线程上）。另一方面，async-await 为您提供了一种进行异步 IO 的便捷方式。 VS 使您能够像同步执行一样调试异步代码。

为了使用纤程，必须调用非托管 API，因为 .NET 在 BCL 中不提供任何托管包装器。 Even the docs of fibers clearly say there isn't a clear advantage to using them:

一般而言，纤维不会比设计良好的纤维提供优势多线程应用程序。 但是，使用纤程可以更轻松地移植旨在安排自己的线程的应用程序。

我想知道使用的优点和缺点是什么 Fibers 与使用新的 async await 和使用 Threads。

使用async-await 可以让您在执行 IO 绑定异步工作的同时感觉自己正在同步执行。任务并行库提供了一种在专用线程上调度工作的简单方法，无论是线程池线程还是新线程，同时允许您挂钩到调度这些工作单元的机制。我真的认为今天使用纤维没有任何优势，因为它提供了所有框架。

我认为您应该告诉您的主要开发人员分别使用任务并行库和async-await 阅读多线程和异步 IO 工作。我认为这会让你们所有人的生活更轻松。

【讨论】：

感谢您的详细解释。对此，我真的非常感激。我认为 Fiber 的最大问题之一是您提到的缺乏 .Net 支持。
+1 附加说明：he knows which thread a particular function has come from and even could access the variables higher in the stack. - 我将其解释为 Fiber 在恢复时会保留其调用堆栈，而异步方法则不会。我认为整体 async/await/TPL 更易于使用和推理，但我可以看到针对它们的调用堆栈调试参数。