在.NET中传递顺序进程

Question

我最近一直在和Go一起工作,我想到也许可以将相同的CSP模型构建到未来的.NET版本中.我不是简单地讨论一个新的库,它使用现有的线程原语来提供通道类型和类似的编程经验/模型; 我的意思是在整个VM和编译器中实现模型,以生成与Go相当的可执行代码(我相信Go生成在事件循环上执行的代码)

这可行吗？以前有人谈过吗？......或者我一直在"喝太多的kool-aid".在完全理解如何实现这一点方面,我绝对不会深入了解这一点.

Answer 1

从一个比 .NET 或 Microsoft 生态系统更熟悉 Go 的人的角度写这篇文章，但尝试使用更嵌入该世界的资源。

Windows 生态系统确实包含某些形式的用户模式任务切换，类似于 Go 的调度程序：光纤似乎回到了 Windows NT 3.51，并且作为一个对开发人员稍微更友好的选项，用户模式调度可用于调度来自您自己的代码的操作系统线程。据我所知，两者都没有暴露于 .NET ( 1 , 2 )。

在上面链接的有关纤程的帖子中，Larry Osterman 解释了到 2005 年它们不再被大量使用的一些原因。一些原因是 Windows API 中纤程的特定怪癖，但其他原因更普遍地适用于用户模式调度。如今执行上下文切换需要几微秒；除非您希望每秒进行数十万次切换，否则这不是问题。由于缓存未命中，切换到对不同数据进行操作的不同代码可能已经导致微秒的延迟，即使完全在用户模式下完成也是如此。用户线程的收益固然很好，但没有理由认为它们是成败的关键。

.NET 中确实有异步编程工具，它们不会创建操作系统管理的线程，尽管这与用户管理的线程不同。async/await使在执行其他操作时在后台运行 I/O 操作变得更加方便，这类似于 goroutines 用于异步网络操作的一些用途 ( 1 , 2 )。在 .NET 中，人们尝试在yield或async/await上构建协程，但这并不意味着这是一个好主意。

我非常喜欢 Go，但正如我建议人们在 Go 中编写惯用的 Go 一样，我会说在 .NET 中编写惯用的 C# 等。在这两种情况下，情况可能都会好起来。

如果您确实发现自己遇到了您认为可能涉及线程的问题，您可以随时检查上下文切换统计信息，看看您是否确实做了足够多的切换，然后如果是这样，请返回到您的代码以找出如何得到这些东西恢复控制。当您没有可用的代码并且这一切都是理论上的时，稍后担心通常胜过过早担心！