英文:
what is the main difference between .net Async and google go light weight thread
问题
当在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.
答案1
得分: 28
-
虽然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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论