.net Async 和 google go 轻量级线程之间的主要区别是什么
当在 go 中调用 runtime.GOMAXPROCS(1) 时，运行时只会为所有 goroutine 使用一个线程。当执行 io 时，你的 goroutine 将会屈服并让其他 goroutine 在同一个线程上运行。
在我看来，这与 .net Async CTP 功能在不使用后台线程时执行协作并发的方式非常相似。
我的问题是，您认为一种方法相对于另一种方法有何优点或缺点。
When calling runtime.GOMAXPROCS(1) in go the runtime will only use one thread for all your goroutines. When doing io your goroutines will yield and let the other goroutines run on the same thread.
This seem very similar to me to how the .net Async CTP feature is doing cooperative concurrency if you are not using background thread.
My question is which advantage or drawback could you think of one methode over the other.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
做出价值判断总是一件棘手的事情，所以我将强调 3 个差异。您可以决定他们是否属于“赞成”或“反对”类别。
虽然 Go 和 async 都允许您以简单的方式编写异步代码，但在 .NET 中，您必须知道代码的哪一部分是异步的，哪一部分不是（即您必须显式使用 async/await关键词）。在 Go 中，您不需要知道这一点 - 运行时使其“正常工作”，没有特殊的语法来标记异步代码。
Go 设计不需要标准库中的任何特殊代码。 .NET 需要为每个异步操作向标准库添加新代码，本质上是在这些情况下使 API 表面加倍，例如，有新的异步 http 下载 API，而旧的非异步 http 下载 API 必须保留以实现向后兼容性。
Go 的设计和实现要简单几个数量级。一小段运行时代码（调度程序）负责挂起阻塞系统调用的 goroutine 并让出睡眠 goroutine。标准库中不需要任何特殊的异步支持。
.NET 实现首先需要添加上述新 API。此外，.NET 实现基于编译器将 async/await 代码重写为等效状态机。它非常聪明，但也相当复杂。实际结果是，第一个异步 CTP 存在已知错误，而 Go 的实现从一开始就几乎可以正常工作。
最终，这并不重要。 async/await 是在 .NET 中编写异步代码的最佳方式。 Goroutines 是在 Go 中实现这一点的最佳方式。两者都很棒，特别是与大多数其他语言的替代品相比。
Making value judgements is always a tricky thing so I'll highlight 3 differences. You decide whether they fall into the "pro" or "con" bucket.
While both Go and async allow you to write async code in a straightforward way, in .NET you have to be aware which part of your code is async and which one isn't (i.e. you have to explicitly use async/await keywords). In Go you don't need to know that - the runtime makes it "just work", there is no special syntax to mark async code.
Go design doesn't require any special code in standard library. .NET required adding new code to the standard library for every async operation, essentially doubling API surface for those cases e.g. there's new async http download API and the old, non-async http download API has to remain for backwards compatibility.
Go design and implementation is orders of magnitude simpler. A small piece of runtime code (scheduler) takes care of suspending goroutines that block on system calls and yielding to sleeping goroutines. There is no need for any special async support in standard library.
.NET implementation first required adding the aforementioned new APIs. Furthermore .NET implementation is based on compiler rewriting code with async/await into an equivalent state machines. It's very clever but also rather complicated. The practical result was that the first async CTP had known bugs while Go's implementation was working pretty much from the beginning.
Ultimately, it doesn't really matter. async/await is the best way to write async code in .NET. Goroutines are the best way to get that in Go. Both are great, especially compared to alternatives in most other languages.