I suspect that you are confusing scheduling with completion. The completion routine for APC based async IO will indeed run in the calling thread and indeed that thread won’t be running at the time of completion - what will happen is that the thread will be scheduled to run. Glossing over a lot of detail, when a CPU becomes available to run it, it will run there. It makes no different what threads might be running on various CPUs in the intervening time as they are not involved in this mechanism except that that might be pre-empted by the scheduler to run the completion routine
Sent from Surface Pro
From: xxxxx@hotmail.com
Sent: Monday, July 06, 2015 4:23 PM
To: Windows System Software Devs Interest List
its said that in case of synchronous I/o request i/o manager doesnt have to bouther about the i/0 issuing thread context, since the i/o completion routine will be returning in the original user thread context which issued the request.
How this can be true since according to my understanding in synchronous i/o the request is waiting for the i/o to complete,and when that thread is waiting for i/o to complete its a blocking call and it can be scheduled out and other thread might be running??
If the IO is synch, then the thread will surely not be executing code in its normal path - that is the definition of synch IO. There is nothing to prevent it from executing an APC or some other KM code. It is far more likely that it will simply be de-scheduled, but it is possible that is was used for something else - this is an implementation detail in the OS
Sent from Surface Pro
From: xxxxx@hotmail.com
Sent: Tuesday, July 07, 2015 5:49 AM
To: Windows System Software Devs Interest List
I understand the things in case of asynchronous I/O where in i know that originator user mode requester thread might not be running at the time I/O completes so the I/O manager queues an APC which runs when originator threads context,till that fine.
Now My doubt is wrt Synchronous I/O,here it is said that originator requestor thread will be running when I/O completes?This is what i am not able to understand.
This happens automatically - if the driver(s) in question return STATUS_SUCCESS directly, then the IO completed in the same thread. If the initial return was STATUS_PENDING, then the completion will be in an arbitrary thread.
Sent from Surface Pro
From: xxxxx@hotmail.com
Sent: Wednesday, July 08, 2015 2:54 PM
To: Windows System Software Devs Interest List
thank you for the answers Mikae, Roberts and Peter.
So now how will the I/O manager now wether the synchronous I/O is already completed in the originator threads context or it hs to queue an APC ?
The reason for alertable waits is that all UM code runs at PASSIVE and cannot be arbitrarily preempted by itself (re-entered). In KM, You can prevent problems by altering IRQL (the nomenclature of which has been Anton’s favoured topic of late if you search the archives), but in UM you have no such ability, so imagine what would happen if code that held an exclusive lock were re-entered and acquired the same lock again. If the lock allowed recursion, the data structure it protected would be corrupted, and it if it did not, the process would deadlock. The answer is an alterable wait - the application declares that it is safe to call the APC now, and indeed the wait is satisfied in case it wanted to do anything about it. IMHO UM APCs have very limited applications; unlike KM APCs that are extremely useful.
alterable waits have no bearing on pre-emption by other contexts as they cannot possibly cause failures (unless your code has timing bugs)
Sent from Surface Pro
From: xxxxx@hotmail.com
Sent: Friday, July 10, 2015 4:43 PM
To: Windows System Software Devs Interest List
One more question here, everybody says that USER MODE APC will run only when the corressponding thread enters alertaible wait?
why this restriction why it cant run immediately after the thread runs as in case of kernel mode APC?
I am not sure if this is a valid question to ask …