当使用 FileStream.WriteAsync() 再次调用该方法时会发生什么

Question

我正在将视频流录制到磁盘。为此，我使用以下代码：

private async Task SaveToFile(IntPtr data, Int32 size)
{
    if (_FileStream == null) return;
    Byte[] buf = new Byte[size];
    Marshal.Copy(data, buf, 0, size);
    //dont await here - just continue
    _FileStream.WriteAsync(buf, 0, size);
}

到目前为止，它似乎没有问题。我只想确认的是，如果在上一次迭代完成之前调用此方法会发生什么。

你会注意到我没有等待WriteAsync() 电话。我不确定这是否正确，但我正在使用的 API 状态以在此方法中将操作保持在最低限度，以免在 API 内部阻塞回调。这似乎是正确的做法，只需将数据传递给流，然后立即返回。

如果最后一次WriteAsync() 通话尚未结束，我再次拨打WriteAsync() 时，谁能确认会发生什么？还是应该awaitWriteAsync() 调用？

编辑： 我还没有使用上述方法遇到异常，所以我想我的最后一个问题是从外部 DLL 回调内部使用 WriteAsync() 时是否有任何影响？ DLL 是第三方 Directshow 组件。我无法验证它在内部是如何工作的，但它只是通过回调为我提供数据，我在其中保存到文件流。

Answer 1

异步重叠WriteAsync 操作没有任何问题，只要它们写入文件的不同、非重叠段：

using System;
using System.Linq;
using System.Threading.Tasks;

namespace ConsoleApplication
{
    class Program
    {
        static void Main(string[] args)
        {
            var tempFile = System.IO.Path.GetTempFileName();
            Console.WriteLine(tempFile);

            var fs = new System.IO.FileStream(
                tempFile, 
                System.IO.FileMode.Create, 
                System.IO.FileAccess.ReadWrite, 
                System.IO.FileShare.ReadWrite, 
                bufferSize: 256,
                useAsync: true);

            fs.SetLength(8192);

            var buff1 = Enumerable.Repeat((byte)0, 2048).ToArray();
            var buff2 = Enumerable.Repeat((byte)0xFF, 2048).ToArray();

            try
            {
                fs.Seek(0, System.IO.SeekOrigin.Begin);
                var task1 = fs.WriteAsync(buff1, 0, buff1.Length);

                fs.Seek(buff1.Length, System.IO.SeekOrigin.Begin);
                var task2 = fs.WriteAsync(buff2, 0, buff2.Length);

                Task.WhenAll(task1, task2).Wait();
                Console.ReadLine();
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex);
            }
        }
    }
}

在底层，这一切都归结为 WriteFile API 和非空 LPOVERLAPPED lpOverlapped，这是 Windows API 中支持的场景。

如果写入确实重叠，您仍然不会看到错误，但写入会竞争，最终结果可能无法预测。

Answer 2

您会注意到我没有等待 WriteAsync() 调用。我不确定这是否正确，但我使用的 API 状态是为了在此方法中将操作保持在最低限度，以免在 API 内部阻塞回调。

您没有显示足够的代码让我们任何人确切地知道您在这里做什么。但是，很明显，您可能需要一些帮助才能准确了解 async 方法的工作原理。

特别是，使用await 语句确实不会阻止方法的执行。事实上，恰恰相反：它会导致方法在该点返回。

它所做的另一件事是为等待的任务设置一个延续，以便当该任务完成时，继续执行。在您的方法中，对 WriteAsync() 方法的调用是该方法所做的最后一件事，因此实际上没有任何延续。但是使用await 会有另一个重要的效果：它允许your 方法返回的Task 正确指示整个方法的完成，包括对WriteAsync() 的调用。

就目前而言，您的方法在调用WriteAsync() 后立即返回（即在写操作实际完成之前），并且在调用者看来它已经完成，即使写操作尚未完成'不一定已经完成。

在您的示例中，您的方法写入一个明显的类成员_FileStream。在第一次完成之前再次调用该方法肯定会很糟糕；我怀疑您是否会遇到异常，但FileStream 绝不保证在您同时执行它们时会一致地写入文件。

这里最好的办法可能是不要使用async 并容忍写入阻塞。如果写入阻塞确实是您使用的 API 的问题，那么您应该使用缓冲区队列和单独的异步操作序列来写入文件，而不是每次 API 调用 WriteAsync()叫你写数据。

Answer 3

FileStream 不是线程安全的。从不同线程写入同一文件的两次写入将无法正常工作。

正如@Noseratio 所指出的，从同一线程对WriteAsync 进行重叠调用很好。

所以如果你是从不同的线程写入文件，你需要同步对文件的访问。

顺便说一句，我还会修改您的 SaveToFile 以返回任务，因为您没有使用 await，所以该方法也不需要是 async。

private Task SaveToFile(IntPtr data, Int32 size)
{
    if (_FileStream == null) return;
    Byte[] buf = new Byte[size];
    Marshal.Copy(data, buf, 0, size);
    //dont await here - just continue
    return _FileStream.WriteAsync(buf, 0, size);
}