在c#（dotnet core 3.1）中似乎不可能在不阻塞原始线程的情况下从非异步方法调用异步函数。为什么？
代码示例：
public async Task myMethodAsync() {
await Task.Delay(5000);
}
public void callingMethhod() {
myMethodAsync().Wait(); // all flavours of this expression, like f.ex. .Result seem to be blocking the calling thread
}
在异步方法完成之前释放调用线程，然后从那里继续执行的技术限制是什么？这在技术上是不可能的吗？
【问题讨论】：
标签： c# multithreading .net-core async-await
是的，这是意料之中的。这就是为什么存在Task 等概念的原因。如果可以做你想做的事：他们不需要——我们可以挥动一根魔杖，一切都将是异步的。等待类型的全部意义在于释放调用线程同时允许稍后继续是困难，并且需要调用代码的协调和参与；以及从什么叫它；等等 - 一直到堆栈到任何正在运行的线程。您的 callingMethhod 代码是同步的：它只能做一些事情：
这样做的影响是async/await具有传染性；任何触及可等待对象的东西有点需要也是可等待的，这意味着：您通常只会从返回 callingMethhod 的 myMethodAsync 调用 [Value]Task[<T>]，并且大概是带有 async 的await（尽管在所示示例中这些位并不是绝对必要的）。
【讨论】：
myMethodAsync 的结果会发生什么（这意味着返回值还是异常）？打电话给callingMethhod 的人是否也知道事情正在展开？如果是这样：如何？它只能看到void - 它对任务一无所知。在调用语义方面：在同步流中间等待只是......无法完成；你可以阻止（通过.Wait() 或.Result），但你真的不应该（这显然是一个非常非常糟糕的主意）
async 方法；现在查看右侧窗格，它显示了编译器为使其工作所做的工作 - 它非常非常复杂，因为调度异步延续本质上是一件复杂的事情：sharplab.io/…
async 方法中，有些事情你不能做，因为无法存储状态 - 任何涉及 ref-locals 的事情，例如 -或者因为线程语义 - 任何使用 lock 的东西，例如
在c#（dotnet core 3.1）中似乎不可能在不阻塞原始线程的情况下从非异步方法调用异步函数。为什么？
因为这就是同步的意思。同步意味着它阻塞线程直到方法完成。
在异步方法完成之前释放调用线程，然后从那里继续执行的技术限制是什么？这在技术上是不可能的吗？
如果你的调用方法想要释放它的线程，那么让它异步。异步方法能够释放它们的调用线程。这里没有什么是不可能的； async和await已经解决了。
现在，如果您问“为什么不能每个方法都隐含为 async”，那么理论上这是可能的，但它会导致几个主要问题。出于向后兼容性的原因，它永远不能在 C# 中完成。立即想到的两个问题是：
async”的语言与任何使用老式线程（Win32 互斥锁等）的东西进行互操作。var x = this._list[0]; this._list.RemoveAt(0); 这样简单的代码也不再安全。【讨论】：