A customer ran into an issue with the Read­Directory­ChangesW function. It was rather complicated, but one corner of the issue boiled down to the following: The customer had multiple asynchronous calls to Read­Directory­ChangesW outstanding. What if anything can be said about the results?

First, we’ll give the answer while wearing kernel-colored glasses: The kernel completes the calls to Read­Directory­ChangesW in the order they were issued, so that the earliest call receives the first available batch of changes, and the next call receives the next available batch of changes, and so on.

Now let’s take off our kernel-colored glasses and see what this means for the application.

Even though the kernel completes the calls in the order they were issued, the fact that the scheduler can preempt a thread at any time means that even though the two operations complete in sequence, the two threads that handle the completion are at the mercy of the scheduler, and they will race against each other, so the end result is unpredictable anyway.