执行新的C＃5.0“异步”和“等待”的关键字使用多个内核？ [英] Do the new C# 5.0 'async' and 'await' keywords use multiple cores?

问题描述

两个新的关键字加入到C＃5.0语言是异步和的await ，这两者说定在不阻塞调用线程异步运行C＃方法。

我的问题是，这些方法实际上是利用多内核和并行运行，还是在异步方法运行在同一个线程核心的来电？

解决方案

  

添加到C＃5.0语言的两个新的关键字异步和等待，这两者的携手并进，而不会阻塞调用线程异步运行C＃方法。

这是整个功能的的目的的获取，但它给了太多的信用，以异步/的await功能。

让我非常，在这一点上是非常明确的： 伺机不会奇迹般地产生异步运行同步方法它不启动了一个新的线程和运行新线程的方法，例如。您呼叫的方法必须知道如何异步运行本身的东西。它是如何选择这样做，是其业务。

  

我的问题是，这些方法实际上是利用多内核和并行运行，还是在异步方法运行在同一个线程核心的来电？

再有，就是完全取决于你打电话的方法。所有这一切等待做的是指示编译器的方法改写成可以作为异步任务的延续传递的委托。也就是说，等待FooAsync（）表示呼叫 FooAsync（）和任何回来必须的东西，再presents刚刚启动的异步操作。告诉大家的东西，当它知道异步操作完成后，它应该调用此委托。委托有被调用时，当前的方法似乎恢复的地方不放过属性。

如果你调用调度方法一起工作到关联到另一个核心另一个线程，太棒了。如果它启动一个计时器，坪UI线程在未来的一些事件处理程序，太棒了。 等待不关心。它是所有可以确保当异步作业完成，控制就可以恢复它离开的地方。

您没问，但也许应该有一个问题是：

  

当异步任务完成和控制拿起它离开的地方，是在同一个线程执行，因为它以前？

这取决于上下文。在等待从UI线程的东西WinForms应用程序，控制再次拿起UI线程上。在一个控制台应用程序，也许不是。

Two new keywords added to the C# 5.0 language are async and await, both of which work hand in hand to run a C# method asynchronously without blocking the calling thread.

My question is, do these methods actually take advantage of multiple cores and run in parallel or does the async method run in the same thread core as the caller?

解决方案

Two new keywords added to the C# 5.0 language are async and await, both of which work hand in hand to run a C# method asynchronously without blocking the calling thread.

That gets across the purpose of the feature, but it gives too much "credit" to the async/await feature.

Let me be very, very clear on this point: await does not magically cause a synchronous method to run asynchronously. It does not start up a new thread and run the method on the new thread, for example. The method you are calling has to be the thing that knows how to run itself asynchronously. How it chooses to do so is its business.

My question is, do these methods actually take advantage of multiple cores and run in parallel or does the async method run in the same thread core as the caller?

Again, that is entirely up to the method you call. All that await does is instruct the compiler to rewrite the method into a delegate that can be passed as the continuation of the asynchronous task. That is, the await FooAsync() means "call FooAsync() and whatever comes back must be something that represents the asynchronous operation that just started up. Tell that thing that when it knows that the asynchronous operation is done, it should call this delegate." The delegate has the property that when it is invoked, the current method appears to resume "where it left off".

If the method you call schedules work onto another thread affinitized to another core, great. If it starts a timer that pings some event handler in the future on the UI thread, great. await doesn't care. All it does is makes sure that when the asynchronous job is done, control can resume where it left off.

A question you did not ask but probably should have is:

When the asynchronous task is finished and control picks up where it left off, is execution in the same thread as it was before?

It depends on the context. In a winforms application where you await something from the UI thread, control picks up again on the UI thread. In a console application, maybe not.

这篇关于执行新的C＃5.0“异步”和“等待”的关键字使用多个内核？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！