我最近一直在使用Go，而且我想到也许可以将相同的CSP模型构建到未来的.NET版本中。我不是简单地讨论一个新的库，它使用现有的线程原语来提供一个通道类型和类似的编程经验/模型;我的意思是在整个VM和编译器中实现模型，以生成可与Go相媲美的可执行代码（我相信Go生成在事件循环上执行的代码）
这可行吗？以前有人谈过吗？......或者我曾经喝过太多的kool-aid＆＃39;。在完全理解如何实现这一点方面，我绝对不会深入了解这一点。
答案 0 :(得分：3)
从更熟悉Go比.NET或Microsoft生态系统的人的角度来写这个，但是尝试使用更多嵌入在这个世界中的来源。
Windows生态系统确实包含某些形式的用户模式任务切换，类似于Go的调度程序：fibers go back to Windows NT 3.51 it seems，并且作为一个更加开发人员友好的选项user-mode scheduling，可以用于从您自己的代码安排操作系统线程。就我所见（1，2）而言，两者都没有暴露给.NET。
在上面关于光纤的帖子中，Larry Osterman解释了它们在2005年不再被大量使用的一些原因。一些原因是Windows API中特定的光纤怪癖，但其他原因更普遍适用于用户模式调度。这些天执行上下文切换需要几微秒;它不是一个问题，除非你期望每秒做数十万个交换机。并且由于缓存未命中，切换到对不同数据进行操作的不同代码可能已经导致微秒延迟，即使完全在用户模式下完成也是如此。用户线程带来的收益很高，但没有理由认为他们已经成功或中断。
你确实在.NET中有异步编程工具，它们不会创建操作系统管理的线程，尽管这与用户管理的线程不同。 async/await让你在执行其他操作时在后台运行I / O操作更方便，这类似于goroutines对异步网络内容的一些用法（1，2 ）。在.NET中，people have tried to build coroutines on yield or async/await，但这并不意味着它是一个好主意。
我喜欢Go go，但正如我建议大家写一些惯用的Go in Go，我会说在.NET中写一些惯用的C＃等。在这两种情况下，它可能会没事的。
如果您做发现自己遇到了可能涉及线程的问题，您可以随时check on context switch stats查看您是否真的做了足够的切换，然后再回到你的代码可以弄清楚如何让事情得到控制。如果你没有工作代码并且理论上都充满理由，那么以后担心往往会过早担心！