FileReader.ReadAsync是否真正异步？

Posted 2021-04-13

所以最近我正在阅读Richter的书通过C＃进行CLR。它是关于.NET Framework 4.5之类的，他指出FileReader.ReadAsync并不是真正的异步，实际上它只是基于同步win32 API的异步包装。我不是.NET Framework开发人员，我使用.NET Core。所以我有几个问题：

1. [使用Task.Run之类包装同步功能的事实对应用程序的扩展有多糟糕？
2. 。NET Core中上述行为是否已解决？如果我说FileReader.ReadAsync，它会异步读取吗？
3. 具有FileOptions.Asynchronous有什么意义，如果您可以基于我调用的方法，例如Read或ReadAsync来确定我希望操作是同步还是异步？
4. 如果WinRT提供了，而win32不提供，为什么不使用WinRT进行异步读取/打开？

答案

FileStream.ReadAsync总是从应用程序级别视图异步读取文件（从某种意义上说，调用在这一点上尚未阻塞，只是将控制权返回给用户代码）。

但是这是真正的还是模拟的异步I / O-取决于FileStream.ReadAsync选项：来自FileOptions.Asynchronous

此选项导致在操作系统上发生异步I / O水平。通过使用此选项，可以避免阻塞ThreadPool线程在许多情况下

这是答案

拥有该FileOptions.Asynchronous有什么意义？>

和来自书本

[创建FileStream对象时，您可以指定是否想通过同步或异步操作进行通信FileOptions.Asynchronous

标志（等效于调用Win32 CreateFile函数，并向其中传递FILE_FLAG_OVERLAPPED旗）。如果未指定此标志，则Windows将执行所有对文件进行同步操作。当然，你仍然可以调用FileStream的ReadAsync方法，并在您的应用程序中就像该操作是异步执行，但在内部执行一样FileStream类使用另一个线程来模拟异步行为;使用此线程很浪费，并且会影响性​​能。在另一方面，您可以通过指定FileOptions.Asynchronous标志。然后您可以调用FileStream的Read执行同步操作的方法。在内部，FileStream类通过启动异步操作来模拟此行为，并且然后立即使调用线程进入睡眠状态，直到操作完成完成了。这也是低效的，但效率不如使用没有构造的FileStream调用ReadAsyncFileOptions.Asynchronous标志

因此这里说FileStream类仅在您未指定

FileOptions.Asynchronous标志的情况下才使用另一个线程来模拟异步行为。

如果WinRT提供WinRT，则为什么不使用WinRT进行异步读取/打开；win32不？

winRT内部总会调用win32（或本机）api。