很明显，如果您使用FILE_FLAG_OVERLAPPED打开文件，则需要提供OVERLAPPED结构，返回ERROR_IO_PENDING时需要等待，如果您不提供{{1 }}在文件句柄上等待。在这种情况下，等待文件句柄是不可靠的，因为任何完成的操作都会发出信号信号文件句柄。
现在，如果打开时没有hEvent，您仍然可以提供FILE_FLAG_OVERLAPPED结构。假设您没有提供hEvent就提供了它，或者根本不提供OVERLAPPED，它在内部有什么作用？如果它正在等待文件句柄，则在使用多个线程中的同一句柄来执行文件IO的多线程应用程序中，这似乎是不可靠的。
如果它是多线程不可靠的，并且每个IO需要一个OVERLAPPED，那么hEvent会涉及多少开销？如果不是，它是否在内部创建一个事件，并且开销是否相同？
我需要在支持库中提供以“重叠”模式打开PhysicalDrive的功能，但是仍然要支持它们“同步”操作。将创建用于重叠的读/写的一组新功能。对于现有的函数调用，我将等待句柄，但是我认为这是一个问题。因此，我可以每次创建一个事件，也可以创建一个共享的一次性事件，并使用CreateEvent来序列化请求，只有这样才能杀死任何NCQ类型的性能提升，尤其是在不使用写缓存的情况下。了解Windows内部的功能将大有帮助。
TIA !!
答案 0 :(得分：0)
是的，这很安全。
给事件或文件句柄加信号是为了用户模式代码等待操作。驱动程序内部使用的是完全不同的同步方案-IRP（I / O请求数据包）。多项操作不会像您担心的那样意外完成错误的请求。
（事实上，在后台没有同步I / O模型。所有I / O都是使用IRP和continuation-passing样式完成的。通过执行异步内核I模拟用户模式下的同步操作/ O，并将当前线程标记为在该操作之前不可运行。请注意，该线程附加在该操作上，而不是事件对象或文件对象上。）