windows - 是否在没有 FILE_FLAG_OVERLAPPED 但使用 OVERLAPPED 结构的情况下以线程安全方式打开同一句柄上的 WriteFile/ReadFile？

Question

很明显，如果你打开一个文件使用FILE_FLAG_OVERLAPPED你需要提供OVERLAPPED结构，你需要在返回时等待ERROR_IO_PENDING，如果你不提供hEvent它在文件句柄上等待。在这种情况下，等待文件句柄是不可靠的，因为任何完成的操作都会向文件句柄发出信号。

现在如果没有打开FILE_FLAG_OVERLAPPED你仍然可以提供OVERLAPPED结构。假设您在没有 hEvent 的情况下提供它或根本没有提供OVERLAPPED，它在内部做什么？如果它正在等待文件句柄，那么在多线程中使用相同句柄进行文件 IO 的多线程应用程序中似乎是不可靠的。

如果它是多线程不可靠的并且hEvent每个 IO 都需要一个，那么涉及多少开销CreateEvent？如果不是，它是否在内部创建一个事件并且它是否具有相同的开销？

我需要在支持库中提供以重叠模式打开 PhysicalDrive 的功能，但仍然支持它们的同步操作。将创建一组用于重叠读/写的新函数。对于现有的函数调用，我打算等待句柄，但我认为这是一个问题。因此，我可以每次创建一个事件，也可以创建一个共享的一次性事件并使用 aMutex来序列化请求，只有这样才能杀死任何 NCQ 类型的性能提升，尤其是在不使用写入缓存的情况下。了解 Windows 在内部做了什么会有很大帮助。

蒂亚！！

标签： windowswinapistorage

Answer 1

是的，它是安全的。

发出事件或文件句柄的信号是为了用户模式代码等待操作。驱动程序内部使用完全不同的同步方案——IRP（I/O 请求包）。多个操作不会像您担心的那样意外完成错误的请求。

（事实上​​，幕后没有同步 I/O 模型。所有 I/O 都是使用 IRP 和 continuation-passing-style 完成的。用户模式下的同步操作通过执行异步内核 I/O 和标记当前线程不可运行挂起该操作。请注意，它挂在操作上，而不是事件对象或文件对象。）