Hi Guys,
I am just a developing a virtual serial driver in UDMF. I want that all IOCTL commands, read should handled sequentially , i,e. processing one at a time. #1. I know, it can be added a mutex lock/unlock in IO request handler. Is this a good method?
#2. Is there IO queue configuration settings make IO requests are dispatched sequentially to driver?
i think you should start by understanding whether you device can be opened mutiple times or only once. in either case, can it be openedd for OVERLAPPED IO or only sequntial. whatever it can be opened for, how will your driver complete the IRPs it recieves?
then understand that even a single device that can be opened by multiple UM processes, and can pend multiple overlapped IOOPs can still provide the guranentee that they will be completed sequentually (from the point of view of when the IO manager recieved them).
IMHO a greatweekness in the design of Windows is that these IO calls must be serialized from the āoutsideā and the true order cannot be reported from within the Kernel, but that problem has existed since NT 3.51
better designed UM processes that need to host network connections, should still plan to pend multiple read IOPs with buffes allocated in UM
IMHO a great weakness in the design of Windows is that these IO calls must be serialized from the āoutsideā and the true order cannot be reported from within the Kernel,
I donāt understand this statement at all. In a system with dynamic scheduling and multiple processors, Iām not sure how you would define ātrue orderā? Would that be the first thread that calls ReadFile and executes one instructionā¦ or the first one to get into kernel-mode in processing that system serviceā¦ or the first one that builds an I/O Request Packet, orā¦ ???
The fact of the matter is, in such systems there IS no āone true orderā ā You call ReadFIle, you get part of the way into that routine, you get rescheduled, somebody ELSE calls ReadFile on the same device, THEY get part of the way into that routineā¦ Whoās āfirstā in the one true order?
Windows simply lays bare this fallacy. If you want order, itās up to YOU to create it. Full stop. Any other solution is just an arbitrary ordering that some will praise and others will āendure.ā
If you want to call ReadFile, and the āfileā itself already exists and so the order of completion of ReadFile requests makes no difference then there is no problem. But if the āfileā in question is a stream of data - as in the case of a TCP stream or in the case of many kinds of device supplied data, the order of completion matters, but cannot be controlled in any way due to thread pre-emption etc. a problem exists.
The choices suck. A single posed read per handle? ā that can starve the producer or at least causes extra memory copies. Multiple posted reads per socket with a UM assigned sequence number assigned while holding a lock preventing other threads from issuing IO on the same handle?
So it does not seem so hard, but then consider what happens once a read completes. The thread that processed one needs to issue another so that the driver wonāt starve. Thatās where the real
problem happens
Which is why serial drivers typically operate in a buffered mode, pulling data from the device and storing it in a ring buffer until a reader can retrieve it. And then also depend on hard or soft flow control to block the transmission from the other end. This decouples the h/w side of read from the s/w side of read.
Itās both more complicatedā¦ and more simpleā¦ than youāre making it sound. Devices and their drivers and their paired DLLs just need to be helpfulā¦ and not developed āthe easiest way possible.ā
Devices buffer data via DMA in buffer pools provided by the driver. No recopy needed. The driver just needs to use the device ring buffer a bit more cleverly than the typical āI set it up once at startup, and copy stuff to the user when itās done.ā
Or you DO the recopy. Small cost these days, really, unless weāre talking about really huge packets, in which case see above.
If the requirement is to serialize the data thatās returned from a device, then thatās what you need to do. The driver provides a sequence number on receive. The app (or a DLL paired with the driver) reorders the data as required.
But this is rarely necessary. A single thread picking off one read completion at a time will typically get the job done.
I had gone through this msdn page and thought of doing a double check on the approaches. Thanks you very much for the comments.
The reason why i am using serial port is that application can ONLY use serial port.
Devices and their drivers and their paired DLLs just need to be helpfulā¦ and not developed āthe easiest way possible.ā
The driver just needs to use the device ring buffer a bit more cleverly than the typical āI set it up once at startup, and copy stuff to the user when itās done.ā