so I’m coming from KMDF where I used to control the processing of a queue (for ioctls) with WdfIoQueueDispatchSerial/Parallel and WdfSynchronizationScopeQueue. Works perfectly on my side.
But now I’m face with a legacy driver which was written with legacy WDM-Framework. Identifying the dispatch routine was easy:
But I’m wondering how the ordering of processing of the IRPs in sDispatchIo is? It must, for some reason, very strict the same order as they are called from the user-app with ::DeviceIoControl(..) → To write to registers of a PCIe device in a specific sequence.
Can I be sure of it? Can it happen that the processing of the IRPs is true parallel/mixed/whatever on a machine with two (or more) processors?
The requests will arrive in order of the calls. Your dispatch routine gets called using the same user-mode thread that called DeviceIoControl, so there’s no reordering possible.
Even if they use overlapped I/O, that doesn’t come into play until you return STATUS_PENDING.
If the UM app makes multiple calls from different threads using the same HANDLE, then the ordering of those calls is arbitrary. If the UM app makes calls from a single thread, or uses a lock to control access to the HANDLE, then the order the top level driver sees them is exactly the same as the order in which the app made them. Normally, lower level drivers see them in the same order too, but some drivers deliberately change the order or introduce constructs that can change the order