在 .NET 中通信顺序进程

Question

我最近一直在使用 Go，我突然想到，也许可以将相同的 CSP 模型构建到 .NET 的未来版本中。我不是简单地谈论一个新的库，它使用引擎盖下的现有线程原语提供通道类型和类似的编程体验/模型；我的意思是在整个 VM 和编译器中实现模型以生成与 Go 相当的可执行代码（我相信 Go 生成在事件循环上执行的代码）

这可行吗？以前有没有讨论过？...或者我'喝了太多的kool-aid'。在完全理解如何实现这一点方面，我绝对超出了我对这个问题的深入了解。

Answer 1

从比 .NET 或微软生态系统更熟悉 Go 的人的角度写这篇文章，但试图使用更嵌入那个世界的源代码。Windows 生态系统确实包括某些形式的用户模式任务切换，类似于 Go 的调度程序所做的：光纤似乎可以追溯到 Windows NT 3.51，并且作为对开发人员更友好的选项，用户模式调度可用于调度来自您自己的代码的操作系统线程。据我所知，两者都没有暴露于 .NET ( 1 , 2 )。在上面链接的关于光纤的帖子中，拉里·奥斯特曼解释了到 2005 年它们不再大量使用的一些原因。一些原因是 Windows API 中光纤的特定怪癖，但其他原因更普遍地适用于用户模式调度。如今，执行上下文切换需要几微秒；除非您期望每秒进行数十万次切换，否则这不是问题。而且由于缓存未命中，即使完全在用户模式下完成，切换到对不同数据进行操作的不同代码也可能已经导致几微秒的延迟。从用户线程中获得的收益很好，但没有理由认为它们是成败的。.NET 中确实有异步编程工具，它们不会创建操作系统管理的线程，尽管这与用户管理的线程不同。async/await使在做其他事情时在后台运行 I/O 操作更方便，这类似于 goroutines 用于异步网络的一些用途 ( 1 , 2 )。在 .NET 中，人们曾尝试在yieldor async/上构建协程await，但这并不意味着这是一个好主意。我非常喜欢 Go，但正如我建议人们在 Go 中编写惯用的 Go 一样，我会说在 .NET 中编写惯用的 C# 等。在这两种情况下，它可能会没事。如果您确实发现自己遇到了一个您认为可能涉及线程的问题，您可以随时检查上下文切换统计信息，看看您是否真的进行了足够多的切换，如果是这样，请返回您的代码以找出您可能会如何获得这些信息回到控制之下。当您没有可用的代码并且这都是理论上的时，以后担心通常比过早担心要好！